Received: from nmta3.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.108]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2ULIWY25490 for ; Fri, 30 Mar 2007 13:18:32 -0800 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta3.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2ULIQ05021219 for ; Fri, 30 Mar 2007 14:18:26 -0700 Received: from [127.0.0.1] (dhcp-79-22-247.jpl.nasa.gov [137.79.22.247]) by xmta1.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2ULIOJi027612 for ; Fri, 30 Mar 2007 14:18:26 -0700 Message-ID: <460D7EA0.9080705@jpl.nasa.gov> Date: Fri, 30 Mar 2007 14:18:24 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] Re(2): [dtn-dev] discussion draft References: <20070328174140.299881629@127.0.0.1> <460D6779.5090408@jpl.nasa.gov> <20070330203409.1848455294@127.0.0.1> <20070330205621.GE23819@grc.nasa.gov> In-Reply-To: <20070330205621.GE23819@grc.nasa.gov> Content-Type: multipart/alternative; boundary="------------020301070900080000010704" X-Source-IP: dhcp-79-22-247.jpl.nasa.gov [137.79.22.247] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. --------------020301070900080000010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wesley Eddy wrote: > On Fri, Mar 30, 2007 at 04:34:09PM -0400, Peter Lovell wrote: > >> SDNVs themselves are limited to 64 bits for reliable operation >> > Did you mean "SDNVs" or "the values within SDNVs"? I think it should be > the values within them, which means the encoded SDNVs would be limited > to 9 bytes. This is how I've capped them in our code when bignum > support isn't available or expected to be needed. You're right, Wes, it's the values that are limited. Section 3.1 of the BP spec says"Implementations of the Bundle Protocol may handle as an invalid numeric value any SDNV that encodes an integer that is larger than (2^64 -- 1)." Where not otherwise limited, as by this clause in the BP spec, an SDNV can in theory contain any non-negative integer value whatsoever. [Practically speaking, your 9-byte limit is fine. Technically, though, the limit in the BP spec means "any number that can be encoded in 64 bits", and in order to encode a 64-bit integer in an SDNV I think you actually need 10 bytes. You can put up to 7 significant bits in each octet, which means you can get a 63-bit integer into (63 / 7) = 9 octets, but for a 64-bit integer you need the low-order bit of one additional octet.] Scott --------------020301070900080000010704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wesley Eddy wrote: 
On Fri, Mar 30, 2007 at 04:34:09PM -0400, Peter Lovell wrote:
  
SDNVs themselves are limited to 64 bits for reliable operation
    
Did you mean "SDNVs" or "the values within SDNVs"?  I think it should be
the values within them, which means the encoded SDNVs would be limited
to 9 bytes.  This is how I've capped them in our code when bignum
support isn't available or expected to be needed.
You're right, Wes, it's the values that are limited.  Section 3.1 of the BP spec says"Implementations of the Bundle Protocol may handle as an invalid numeric value any SDNV that encodes an integer that is larger than (2^64 – 1)."

Where not otherwise limited, as by this clause in the BP spec, an SDNV can in theory contain any non-negative integer value whatsoever.

[Practically speaking, your 9-byte limit is fine.  Technically, though, the limit in the BP spec means "any number that can be encoded in 64 bits", and in order to encode a 64-bit integer in an SDNV I think you actually need 10 bytes.  You can put up to 7 significant bits in each octet, which means you can get a 63-bit integer into (63 / 7) = 9 octets, but for a 64-bit integer you need the low-order bit of one additional octet.]

Scott

--------------020301070900080000010704-- Received: from mta3.srv.hcvlny.cv.net (mta3.srv.hcvlny.cv.net [167.206.4.198]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2ULFVY25460 for ; Fri, 30 Mar 2007 13:15:31 -0800 Received: from [192.168.1.4] (ool-45745556.dyn.optonline.net [69.116.85.86]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JFQ00EKTJ1PQIH0@mta3.srv.hcvlny.cv.net> for dtn-interest@mailman.dtnrg.org; Fri, 30 Mar 2007 17:15:25 -0400 (EDT) Date: Fri, 30 Mar 2007 17:15:35 -0400 From: Michael Demmer Subject: Re: [dtn-interest] Re: [dtn-dev] discussion draft In-reply-to: <460D7B78.9090101@jpl.nasa.gov> To: Scott Burleigh Cc: dtn interest Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: multipart/alternative; boundary="Boundary_(ID_c1GqtOfVBHt8WxHWlK/Grg)" X-Applemailsentby: demmer References: <20070328174140.299881629@127.0.0.1> <460BCE8A.30305@cs.tcd.ie> <20070329153824.1743585704@127.0.0.1> <460BE151.3090700@cs.tcd.ie> <460BE890.5080008@jpl.nasa.gov> <460BEAC8.50703@cs.tcd.ie> <460D25DB.107@cs.tcd.ie> <20070330165742.1638015056@127.0.0.1> <20070330171643.640617612@127.0.0.1> <460D5186.4050902@jpl.nasa.gov> <20070330184037.1421532388@127.0.0.1> <460D6779.5090408@jpl.nasa.gov> <20070330203409.1848455294@127.0.0.1> <460D7B78.9090101@jpl.nasa.gov> Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: --Boundary_(ID_c1GqtOfVBHt8WxHWlK/Grg) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT On Mar 30, 2007, at 5:04 PM, Scott Burleigh wrote: > Peter Lovell wrote: >> On Fri, Mar 30, 2007, Scott Burleigh >> wrote: >> >>>> On Fri, Mar 30, 2007, Scott Burleigh >>>> wrote: >>>> >>>>>> On Fri, Mar 30, 2007, Peter Lovell >>>>>> wrote: >>>>>> >> Lots of people wrote lots of stuff. For convenience of list-members, >> here's a condensed summary ... >> >> 1. there was an error in Figure 2 of the attachment. The length field >> should have followed the references, as described in the text. It >> should >> look like this >> >> >> >> +-----------+-----------+-----------+-----------+ >> |type | flags (SDNV) | >> +-----------+-----------+-----------+-----------+ >> | EID reference count (SDNV) | >> +-----------+-----------+-----------+-----------+ >> | ref_scheme_1 (SDNV) | ref_ssp_1 (SDNV) | >> +-----------+-----------+-----------+-----------+ >> | ref_scheme_2 (SDNV) | ref_ssp_2 (SDNV) | >> +-----------+-----------+-----------+-----------+ >> | length (SDNV) | >> +-----------+-----------+-----------+-----------+ >> | block-type-specific data | >> +-----------+-----------+-----------+-----------+ >> = (continues ... ) = >> +-----------+-----------+-----------+-----------+ >> | block-type-specific data | >> +-----------+-----------+-----------+-----------+ >> >> A sample block layout showing two EID references >> >> Figure 2 >> >> >> 2. the comment about "payload block" was narrative and for an earlier >> purpose. We don't intend that to be in BP spec itself. >> >> 3. the version change (needed because of other, earlier changes) >> necessitates revision of all implementations. We had included, as an >> either/or concession to ease transition, the ability to still use >> [old- >> style] EID references stored in private data. But that is no longer >> beneficial. So, EID references in extension blocks MUST be in the >> list, >> and only in the list. This allows us to get rid of the funky must- >> set- >> flags rules, a good improvement. This means that BP section 3.7 >> paras 2 >> and 3 go away. >> >> [EIDs as text can continue to be anywhere, of course] >> >> 4. there used to be a limit somewhere on dictionary size but it >> seems to >> have gone away. So we should no longer make mention of "16-bit >> unsigned >> integers" etc. SDNVs themselves are limited to 64 bits for >> reliable operation >> >> Regards.....Peter > Perfect. > +1 I like this, do it Me too. -mike --Boundary_(ID_c1GqtOfVBHt8WxHWlK/Grg) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
On Mar 30, 2007, at 5:04 PM, Scott Burleigh wrote:

Peter Lovell wrote: 
On Fri, Mar 30, 2007, Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> wrote:
  
On Fri, Mar 30, 2007, Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> wrote:
      
On Fri, Mar 30, 2007, Peter Lovell <peter.lovell@sparta.com> wrote:
          
Lots of people wrote lots of stuff. For convenience of list-members,
here's a condensed summary ...

1. there was an error in Figure 2 of the attachment. The length field
should have followed the references, as described in the text. It should
look like this



   +-----------+-----------+-----------+-----------+
   |type       |      flags (SDNV)                 |
   +-----------+-----------+-----------+-----------+
   |           EID reference count (SDNV)          |
   +-----------+-----------+-----------+-----------+
   |  ref_scheme_1 (SDNV)  |    ref_ssp_1 (SDNV)   |
   +-----------+-----------+-----------+-----------+
   |  ref_scheme_2 (SDNV)  |    ref_ssp_2 (SDNV)   |
   +-----------+-----------+-----------+-----------+
   |            length  (SDNV)                     |
   +-----------+-----------+-----------+-----------+
   |  block-type-specific data                     |
   +-----------+-----------+-----------+-----------+
   =    (continues ... )                           =
   +-----------+-----------+-----------+-----------+
   |  block-type-specific data                     |
   +-----------+-----------+-----------+-----------+

   A sample block layout showing two EID references

                                 Figure 2


2. the comment about "payload block" was narrative and for an earlier
purpose. We don't intend that to be in BP spec itself.

3. the version change (needed because of other, earlier changes)
necessitates revision of all implementations. We had included, as an
either/or concession to ease transition, the ability to still use [old-
style] EID references stored in private data. But that is no longer
beneficial. So, EID references in extension blocks MUST be in the list,
and only in the list. This allows us to get rid of the funky must-set-
flags rules, a good improvement. This means that BP section 3.7 paras 2
and 3 go away.

[EIDs as text can continue to be anywhere, of course]

4. there used to be a limit somewhere on dictionary size but it seems to
have gone away. So we should no longer make mention of "16-bit unsigned
integers" etc. SDNVs themselves are limited to 64 bits for reliable operation

Regards.....Peter
Perfect.
+1 I like this, do it
Me too.
-mike




--Boundary_(ID_c1GqtOfVBHt8WxHWlK/Grg)-- Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2ULAuY25409 for ; Fri, 30 Mar 2007 13:10:56 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2ULAqgh020296; Fri, 30 Mar 2007 16:10:52 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2ULAqSP011947; Fri, 30 Mar 2007 16:10:52 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 17:10:51 -0400 From: "Peter Lovell" To: "Wesley Eddy" Cc: "Scott Burleigh" , "dtn interest" Subject: Re(2): [dtn-interest] Re(2): [dtn-dev] discussion draft Date: Fri, 30 Mar 2007 17:10:50 -0400 Message-Id: <20070330211050.1921243575@127.0.0.1> In-Reply-To: <20070330205621.GE23819@grc.nasa.gov> References: <20070328174140.299881629@127.0.0.1> <460D6779.5090408@jpl.nasa.gov> <20070330203409.1848455294@127.0.0.1> <20070330205621.GE23819@grc.nasa.gov> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 21:10:51.0648 (UTC) FILETIME=[E5902000:01C7730F] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Fri, 30 Mar 2007 16:10:52 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, Mar 30, 2007, Wesley Eddy wrote: >On Fri, Mar 30, 2007 at 04:34:09PM -0400, Peter Lovell wrote: >> SDNVs themselves are limited to 64 bits for reliable operation > >Did you mean "SDNVs" or "the values within SDNVs"? I think it should be >the values within them, which means the encoded SDNVs would be limited >to 9 bytes. This is how I've capped them in our code when bignum >support isn't available or expected to be needed. The limit is on the values themselves and is already described in BP spec. I was just mentioning it to contrast with the earlier value. The encoding limit is actually 10 bytes as you can get only 63 bits into 9 bytes. Thanks.....Peter Received: from nmta3.jpl.nasa.gov (nmta3.jpl.nasa.gov [137.78.160.108]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2UL5DY25321 for ; Fri, 30 Mar 2007 13:05:13 -0800 Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta3.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2UL58wa017213 for ; Fri, 30 Mar 2007 14:05:08 -0700 Received: from [127.0.0.1] (dhcp-79-22-247.jpl.nasa.gov [137.79.22.247]) by xmta3.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2UL4uqS029043 for ; Fri, 30 Mar 2007 14:05:07 -0700 Message-ID: <460D7B78.9090101@jpl.nasa.gov> Date: Fri, 30 Mar 2007 14:04:56 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest References: <20070328174140.299881629@127.0.0.1> <460BCE8A.30305@cs.tcd.ie> <20070329153824.1743585704@127.0.0.1> <460BE151.3090700@cs.tcd.ie> <460BE890.5080008@jpl.nasa.gov> <460BEAC8.50703@cs.tcd.ie> <460D25DB.107@cs.tcd.ie> <20070330165742.1638015056@127.0.0.1> <20070330171643.640617612@127.0.0.1> <460D5186.4050902@jpl.nasa.gov> <20070330184037.1421532388@127.0.0.1> <460D6779.5090408@jpl.nasa.gov> <20070330203409.1848455294@127.0.0.1> In-Reply-To: <20070330203409.1848455294@127.0.0.1> Content-Type: multipart/alternative; boundary="------------050206050105020903070304" X-Source-IP: dhcp-79-22-247.jpl.nasa.gov [137.79.22.247] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: [dtn-interest] Re: [dtn-dev] discussion draft Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. --------------050206050105020903070304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Lovell wrote: > On Fri, Mar 30, 2007, Scott Burleigh wrote: > >>> On Fri, Mar 30, 2007, Scott Burleigh wrote: >>> >>>>> On Fri, Mar 30, 2007, Peter Lovell wrote: >>>>> > > Lots of people wrote lots of stuff. For convenience of list-members, > here's a condensed summary ... > > 1. there was an error in Figure 2 of the attachment. The length field > should have followed the references, as described in the text. It should > look like this > > > > +-----------+-----------+-----------+-----------+ > |type | flags (SDNV) | > +-----------+-----------+-----------+-----------+ > | EID reference count (SDNV) | > +-----------+-----------+-----------+-----------+ > | ref_scheme_1 (SDNV) | ref_ssp_1 (SDNV) | > +-----------+-----------+-----------+-----------+ > | ref_scheme_2 (SDNV) | ref_ssp_2 (SDNV) | > +-----------+-----------+-----------+-----------+ > | length (SDNV) | > +-----------+-----------+-----------+-----------+ > | block-type-specific data | > +-----------+-----------+-----------+-----------+ > = (continues ... ) = > +-----------+-----------+-----------+-----------+ > | block-type-specific data | > +-----------+-----------+-----------+-----------+ > > A sample block layout showing two EID references > > Figure 2 > > > 2. the comment about "payload block" was narrative and for an earlier > purpose. We don't intend that to be in BP spec itself. > > 3. the version change (needed because of other, earlier changes) > necessitates revision of all implementations. We had included, as an > either/or concession to ease transition, the ability to still use [old- > style] EID references stored in private data. But that is no longer > beneficial. So, EID references in extension blocks MUST be in the list, > and only in the list. This allows us to get rid of the funky must-set- > flags rules, a good improvement. This means that BP section 3.7 paras 2 > and 3 go away. > > [EIDs as text can continue to be anywhere, of course] > > 4. there used to be a limit somewhere on dictionary size but it seems to > have gone away. So we should no longer make mention of "16-bit unsigned > integers" etc. SDNVs themselves are limited to 64 bits for reliable operation > > Regards.....Peter Perfect. +1 I like this, do it Scott --------------050206050105020903070304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Lovell wrote: 
On Fri, Mar 30, 2007, Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> wrote:
  
On Fri, Mar 30, 2007, Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> wrote:
      
On Fri, Mar 30, 2007, Peter Lovell <peter.lovell@sparta.com> wrote:
          

Lots of people wrote lots of stuff. For convenience of list-members,
here's a condensed summary ...

1. there was an error in Figure 2 of the attachment. The length field
should have followed the references, as described in the text. It should
look like this



   +-----------+-----------+-----------+-----------+
   |type       |      flags (SDNV)                 |
   +-----------+-----------+-----------+-----------+
   |           EID reference count (SDNV)          |
   +-----------+-----------+-----------+-----------+
   |  ref_scheme_1 (SDNV)  |    ref_ssp_1 (SDNV)   |
   +-----------+-----------+-----------+-----------+
   |  ref_scheme_2 (SDNV)  |    ref_ssp_2 (SDNV)   |
   +-----------+-----------+-----------+-----------+
   |            length  (SDNV)                     |
   +-----------+-----------+-----------+-----------+
   |  block-type-specific data                     |
   +-----------+-----------+-----------+-----------+
   =    (continues ... )                           =
   +-----------+-----------+-----------+-----------+
   |  block-type-specific data                     |
   +-----------+-----------+-----------+-----------+

   A sample block layout showing two EID references

                                 Figure 2


2. the comment about "payload block" was narrative and for an earlier
purpose. We don't intend that to be in BP spec itself.

3. the version change (needed because of other, earlier changes)
necessitates revision of all implementations. We had included, as an
either/or concession to ease transition, the ability to still use [old-
style] EID references stored in private data. But that is no longer
beneficial. So, EID references in extension blocks MUST be in the list,
and only in the list. This allows us to get rid of the funky must-set-
flags rules, a good improvement. This means that BP section 3.7 paras 2
and 3 go away.

[EIDs as text can continue to be anywhere, of course]

4. there used to be a limit somewhere on dictionary size but it seems to
have gone away. So we should no longer make mention of "16-bit unsigned
integers" etc. SDNVs themselves are limited to 64 bits for reliable operation

Regards.....Peter
Perfect.
+1 I like this, do it
Scott
--------------050206050105020903070304-- Received: from mx1.grc.nasa.gov (mx1.grc.nasa.gov [128.156.11.68]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2UL0WY25214 for ; Fri, 30 Mar 2007 13:00:32 -0800 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 1F829C208 for ; Fri, 30 Mar 2007 17:00:22 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2UL0M9Q026368; Fri, 30 Mar 2007 17:00:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2UL0H2k006920; Fri, 30 Mar 2007 17:00:17 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id v7Ap+CzqREDt; Fri, 30 Mar 2007 17:00:17 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2UL0H2j006916;Fri, 30 Mar 2007 17:00:17 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 12BD14FE21; Fri, 30 Mar 2007 16:56:21 -0400 (EDT) Date: Fri, 30 Mar 2007 16:56:21 -0400 From: Wesley Eddy To: Peter Lovell Cc: Scott Burleigh , dtn interest Subject: Re: [dtn-interest] Re(2): [dtn-dev] discussion draft Message-ID: <20070330205621.GE23819@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <20070328174140.299881629@127.0.0.1> <460D6779.5090408@jpl.nasa.gov> <20070330203409.1848455294@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070330203409.1848455294@127.0.0.1> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:69.97115 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, Mar 30, 2007 at 04:34:09PM -0400, Peter Lovell wrote: > SDNVs themselves are limited to 64 bits for reliable operation Did you mean "SDNVs" or "the values within SDNVs"? I think it should be the values within them, which means the encoded SDNVs would be limited to 9 bytes. This is how I've capped them in our code when bignum support isn't available or expected to be needed. Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2UKn6Y25106 for ; Fri, 30 Mar 2007 12:49:07 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2UKn3FS019364; Fri, 30 Mar 2007 15:49:04 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2UKn314011043; Fri, 30 Mar 2007 15:49:04 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 16:49:03 -0400 From: "Peter Lovell" To: "Stephen Farrell" , "dtn interest" Subject: Re(2): [dtn-interest] dicsussion draft for dtn-interest Date: Fri, 30 Mar 2007 16:49:01 -0400 Message-Id: <20070330204901.602045338@127.0.0.1> In-Reply-To: <460D5169.8060201@cs.tcd.ie> References: <20070330174705.330139065@127.0.0.1> <460D5169.8060201@cs.tcd.ie> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 20:49:03.0163 (UTC) FILETIME=[D9A528B0:01C7730C] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Fri, 30 Mar 2007 15:49:04 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, Mar 30, 2007, Stephen Farrell wrote: > >Ok, so to be sure that we all want to do this, can you >send a message under this thread in the next week saying: > >+1 I like this, do it >-1 I don't want to do that > >If (as I suspect) we do want to include the change (all the >implementers seem to anyway as far as we know), then Keith >will issue a revised I-D at the end of the next week >containing the change. > >S. > >PS: This is being a bit formal for an IRTF RG, but since >we're 1/2 way through the IRSG review for this I think its >worth doing this way. +1 I like this, do it Cheers.....Peter p.s. I promise to vote only once :) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2UKYEY25001 for ; Fri, 30 Mar 2007 12:34:14 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2UKYB9i018756; Fri, 30 Mar 2007 15:34:11 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2UKYBuo010329; Fri, 30 Mar 2007 15:34:11 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 16:34:10 -0400 From: "Peter Lovell" To: "Scott Burleigh" , "dtn interest" Date: Fri, 30 Mar 2007 16:34:09 -0400 Message-Id: <20070330203409.1848455294@127.0.0.1> In-Reply-To: <460D6779.5090408@jpl.nasa.gov> References: <20070328174140.299881629@127.0.0.1> <460BCE8A.30305@cs.tcd.ie> <20070329153824.1743585704@127.0.0.1> <460BE151.3090700@cs.tcd.ie> <460BE890.5080008@jpl.nasa.gov> <460BEAC8.50703@cs.tcd.ie> <460D25DB.107@cs.tcd.ie> <20070330165742.1638015056@127.0.0.1> <20070330171643.640617612@127.0.0.1> <460D5186.4050902@jpl.nasa.gov> <20070330184037.1421532388@127.0.0.1> <460D6779.5090408@jpl.nasa.gov> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==_20070330203409.1848455294-1_==" X-OriginalArrivalTime: 30 Mar 2007 20:34:10.0554 (UTC) FILETIME=[C59BD5A0:01C7730A] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Fri, 30 Mar 2007 15:34:11 -0500 (CDT) Subject: [dtn-interest] Re(2): [dtn-dev] discussion draft Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: --==_20070330203409.1848455294-1_== Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, Mar 30, 2007, Scott Burleigh wrote: >> On Fri, Mar 30, 2007, Scott Burleigh wrote: >>>> On Fri, Mar 30, 2007, Peter Lovell wrote: Lots of people wrote lots of stuff. For convenience of list-members, here's a condensed summary ... 1. there was an error in Figure 2 of the attachment. The length field should have followed the references, as described in the text. It should look like this +-----------+-----------+-----------+-----------+ |type | flags (SDNV) | +-----------+-----------+-----------+-----------+ | EID reference count (SDNV) | +-----------+-----------+-----------+-----------+ | ref_scheme_1 (SDNV) | ref_ssp_1 (SDNV) | +-----------+-----------+-----------+-----------+ | ref_scheme_2 (SDNV) | ref_ssp_2 (SDNV) | +-----------+-----------+-----------+-----------+ | length (SDNV) | +-----------+-----------+-----------+-----------+ | block-type-specific data | +-----------+-----------+-----------+-----------+ = (continues ... ) = +-----------+-----------+-----------+-----------+ | block-type-specific data | +-----------+-----------+-----------+-----------+ A sample block layout showing two EID references Figure 2 2. the comment about "payload block" was narrative and for an earlier purpose. We don't intend that to be in BP spec itself. 3. the version change (needed because of other, earlier changes) necessitates revision of all implementations. We had included, as an either/or concession to ease transition, the ability to still use [old- style] EID references stored in private data. But that is no longer beneficial. So, EID references in extension blocks MUST be in the list, and only in the list. This allows us to get rid of the funky must-set- flags rules, a good improvement. This means that BP section 3.7 paras 2 and 3 go away. [EIDs as text can continue to be anywhere, of course] 4. there used to be a limit somewhere on dictionary size but it seems to have gone away. So we should no longer make mention of "16-bit unsigned integers" etc. SDNVs themselves are limited to 64 bits for reliable operation Regards.....Peter --==_20070330203409.1848455294-1_== Content-Type: text/plain; name="draft-irtf-dtnrg-bundle-EIDrefs-02.txt"; x-mac-type="00000000"; x-mac-creator="00000000" Content-Disposition: attachment Content-Transfer-Encoding: base64 CgoKRFROIFJlc2VhcmNoIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUC4gTG92ZWxsCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNQQVJUQSwgSW5jLgpFeHBpcmVzOiBPY3Rv YmVyIDEsIDIwMDcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMzAs IDIwMDcKCgogICAgICAgICAgICAgICAgICAgIERUTiBFSUQgUmVmZXJlbmNlcyBTcGVjaWZp Y2F0aW9uCiAgICAgICAgICAgICAgICAgICBkcmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1FSURy ZWZzLTAyCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50 ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBwbGlj YWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMg YXdhcmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdo aWNoIGhlIG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBh Y2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAg IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMu ICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBv ZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxpc3Qgb2Yg SW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdAog ICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiBPY3RvYmVyIDEsIDIwMDcuCgpDb3B5cmlnaHQgTm90aWNl CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3KS4KCgoKCgoKCgoKCgoK CgoKTG92ZWxsICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxLCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBF SUQgcmVmZXJlbmNlcyAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDA3CgoKQWJzdHJhY3QK CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgY29udmVudGlvbiBmb3Igc3RvcmluZyBy ZWZlcmVuY2VzIHRvIERlbGF5LQogICBUb2xlcmFudCBOZXR3b3JraW5nIChEVE4pIEJ1bmRs ZSBQcm90b2NvbCAoQlApIGVuZHBvaW50IGlkZW50aWZpZXJzCiAgIFtFSURzXSB3aXRoaW4g ZXh0ZW5zaW9uIGJsb2NrcyBvZiBidW5kbGVzLgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAx LiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDMKICAgMi4gIFN0b3JhZ2UgQ29udmVudGlvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgICAgMi4xLiAgRUlEIFJlZmVy ZW5jZSBMaXN0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAog ICAzLiAgRGljdGlvbmFyeSBSZXZpc2lvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDYKICAgNC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgIDUuICBSZWZlcmVuY2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg OAogICAgIDUuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgICA1LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgIEF1dGhvcidzIEFk ZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRz IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpMb3ZlbGwgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDEsIDIwMDcgICAg ICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVJ RCByZWZlcmVuY2VzICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDcKCgoxLiAgSW50cm9k dWN0aW9uCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVE IiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJS RUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gWzFdLgoKICAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGFuIG9wdGlvbmFsIG1ldGhvZCBmb3IgZXh0ZW5zaW9ucyB0byB0 aGUgRFROCiAgIGJ1bmRsZSBwcm90b2NvbCBbMl0gdG8gc3RvcmUgcmVmZXJlbmNlcyB0byBl bmRwb2ludCBhZGRyZXNzZXMgaW4gdGhlCiAgIGJ1bmRsZSBkaWN0aW9uYXJ5LiAgRUlEcyBh bmQgdGhlIHJlZmVyZW5jZSBmb3JtYXQgYXJlIGRlc2NyaWJlZCBpbgogICBbMl0gc2VjdGlv biAzLjUuCgogICBUaGUgcHJpbWFyeSBibG9jayBvZiBlYWNoIGJ1bmRsZSBjb250YWlucyBh ICJkaWN0aW9uYXJ5IiBieXRlIGFycmF5LgogICBUaGUgdGV4dCB2YWx1ZXMgb2YgdGhlIGVu ZHBvaW50IGlkZW50aWZpZXJzIGluIHRoZSBwcmltYXJ5IGJsb2NrLAogICBzdWNoIGFzIHNv dXJjZSBhbmQgZGVzdGluYXRpb24sIGFyZSBzdG9yZWQgaW4gdGhlIGRpY3Rpb25hcnkgYW5k CiAgIHJlZmVyZW5jZXMgdG8gdGhlbSBhcmUgc3RvcmVkIGluIHNwZWNpZmljIHBsYWNlcyBp biB0aGUgcHJpbWFyeQogICBibG9jay4KCiAgIERUTiBwcm90b2NvbCBleHRlbnNpb25zIG1h eSBhbHNvIGFkZCBlbmRwb2ludCBpZGVudGlmaWVycyB0byB0aGUKICAgZGljdGlvbmFyeSBh bmQgc3RvcmUgcmVmZXJlbmNlcyB3aXRoaW4gdGhlaXIgZXh0ZW5zaW9uIGJsb2Nrcy4KCiAg IFRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgYXQgZWFjaCBub2RlIG1heSB3aXNoIHRvIHJl bW92ZSBhbnkKICAgZGljdGlvbmFyeSBlbnRyaWVzIGZvciB3aGljaCByZWZlcmVuY2VzIG5v IGxvbmdlciBleGlzdCBhbmQsIHRvIGRvCiAgIHNvLCBtdXN0IGJlIGFibGUgdG8gbG9jYXRl IGFsbCBleGlzdGluZyBFSUQgcmVmZXJlbmNlcyBpbiBhIGJ1bmRsZS4KCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCkxvdmVsbCAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9i ZXIgMSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgRUlEIHJlZmVyZW5jZXMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAw NwoKCjIuICBTdG9yYWdlIENvbnZlbnRpb24KCiAgIEFsbCBleHRlbnNpb24gYmxvY2tzIHVz ZSB0aGUgQ2Fub25pY2FsIEJ1bmRsZSBCbG9jayBGb3JtYXQgYXMgZGVmaW5lZAogICBpbiB0 aGUgQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24uICBFYWNoIGlzIGNvbXByaXNlZCBv ZiB0aGUKICAgZm9sbG93aW5nIGVsZW1lbnRzOgoKICAgICAgLSBCbG9jayB0eXBlIGNvZGUK CiAgICAgIC0gQmxvY2sgcHJvY2Vzc2luZyBjb250cm9sIGZsYWdzCgogICAgICAtIEJsb2Nr IEVJRCByZWZlcmVuY2UgbGlzdCAob3B0aW9uYWwpCgogICAgICAtIEJsb2NrIGRhdGEgbGVu Z3RoCgogICAgICAtIEJsb2NrLXR5cGUtc3BlY2lmaWMgZGF0YSBmaWVsZHMKCiAgIFRoZSB0 eXBlLCBmbGFncywgbGlzdCBhbmQgbGVuZ3RoIGZpZWxkcyBhcmUgY29tbW9uIHRvIGFsbCBl eHRlbnNpb24KICAgYmxvY2tzIGFuZCBhcmUga25vd24gY29sbGVjdGl2ZWx5IGFzIHRoZSAi cHJlYW1ibGUiLgoKCiAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSst LS0tLS0tLS0tLSsKICAgfHR5cGUgICAgICAgfCAgICAgIGZsYWdzIChTRE5WKSAgICAgICAg ICAgICAgICAgfAogICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0rCiAgIHwgICAgICAgICAgICBsZW5ndGggIChTRE5WKSAgICAgICAgICAgICAg ICAgICAgIHwKICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tKwogICB8ICBibG9jayBib2R5IGRhdGEgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0t LS0tLSsKICAgPSAgICAgKGNvbnRpbnVlcyAuLi4gKSAgICAgICAgICAgICAgICAgICAgICAg ICAgPQogICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0rCiAgIHwgIGJsb2NrIGJvZHkgZGF0YSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t KwoKICAgR2VuZXJhbCBibG9jayBsYXlvdXQgKHdpdGhvdXQgbGlzdCkKCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxCgogICBFSUQgcmVmZXJlbmNlcyBNVVNU IGJlIHN0b3JlZCBpbiB0aGUgRUlEIHJlZmVyZW5jZSBsaXN0CgoyLjEuICBFSUQgUmVmZXJl bmNlIExpc3QKCiAgIFRoZSBFSUQgcmVmZXJlbmNlIGxpc3QgaXMgYSBjb21wb3NpdGUgZmll bGQgYW5kIG1heSBvcHRpb25hbGx5IGJlCiAgIHByZXNlbnQgaW4gYW55IGV4dGVuc2lvbiBi bG9jay4gIEl0IGNvbnNpc3RzIG9mIGEgY291bnQgZmllbGQKICAgZm9sbG93ZWQgYnkgdGhh dCBudW1iZXIgb2YgcmVmZXJlbmNlcy4gIFRoZSBjb3VudCBpcyBhbiBTRE5WIGFzCiAgIGRl c2NyaWJlZCBpbiBbMl0gc2VjdGlvbiAzLjEuICBFYWNoIHJlZmVyZW5jZSBpcyBhIG9yZGVy ZWQgcGFpciBvZgogICBTRE5WcyBhcyBkZXNjcmliZWQgaW4gWzJdIHNlY3Rpb24gMy41LCBj b250YWluaW5nOgoKICAgICAgLSB0aGUgb2Zmc2V0LCB3aXRoaW4gdGhlIGRpY3Rpb25hcnks IG9mIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgdGhlCiAgICAgIHJlZmVyZW5jZWQgZW5kcG9p bnQgSUQncyBzY2hlbWUgbmFtZQoKCgpMb3ZlbGwgICAgICAgICAgICAgICAgICAgRXhwaXJl cyBPY3RvYmVyIDEsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgIEVJRCByZWZlcmVuY2VzICAgICAgICAgICAgICAgICAgIE1h cmNoIDIwMDcKCgogICAgICAtIHRoZSBvZmZzZXQsIHdpdGhpbiB0aGUgZGljdGlvbmFyeSwg b2YgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiB0aGUKICAgICAgcmVmZXJlbmNlZCBlbmRwb2lu dCBJRCdzIFNTUAoKICAgUHJlc2VuY2Ugb2YgdGhlIGZpZWxkIGlzIGluZGljYXRlZCBieSB0 aGUgc2V0dGluZyBvZiBiaXQgMHg0MCBvZiB0aGUKICAgYmxvY2sgcHJvY2Vzc2luZyBjb250 cm9sIGZsYWdzLgoKICAgSWYgYml0IDB4NDAgaXMgbm90IHNldCB0aGVuIHRoZXJlIGlzIG5v IEVJRCByZWZlcmVuY2UgbGlzdCBmaWVsZCwgYW5kCiAgIG5laXRoZXIgY291bnQgbm9yIHJl ZmVyZW5jZXMgbWF5IGFwcGVhci4KCgogICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgIHx0eXBlICAgICAgIHwgICAgICBmbGFncyAoU0RO VikgICAgICAgICAgICAgICAgIHwKICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tKwogICB8ICAgICAgICAgICBFSUQgcmVmZXJlbmNlIGNvdW50 IChTRE5WKSAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0t LS0tLSstLS0tLS0tLS0tLSsKICAgfCAgcmVmX3NjaGVtZV8xIChTRE5WKSAgfCAgICByZWZf c3NwXzEgKFNETlYpICAgfAogICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0rCiAgIHwgIHJlZl9zY2hlbWVfMiAoU0ROVikgIHwgICAgcmVmX3Nz cF8yIChTRE5WKSAgIHwKICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tKwogICB8ICAgICAgICAgICAgbGVuZ3RoICAoU0ROVikgICAgICAgICAg ICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSst LS0tLS0tLS0tLSsKICAgfCAgYmxvY2stdHlwZS1zcGVjaWZpYyBkYXRhICAgICAgICAgICAg ICAgICAgICAgfAogICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0rCiAgID0gICAgKGNvbnRpbnVlcyAuLi4gKSAgICAgICAgICAgICAgICAgICAg ICAgICAgID0KICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tKwogICB8ICBibG9jay10eXBlLXNwZWNpZmljIGRhdGEgICAgICAgICAgICAgICAg ICAgICB8CiAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0t LS0tLSsKCiAgIEEgc2FtcGxlIGJsb2NrIGxheW91dCBzaG93aW5nIHR3byBFSUQgcmVmZXJl bmNlcwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDIKCiAgIEV4 dGVuc2lvbiBibG9ja3MgbWF5IGNvbnRhaW4gRUlEIGFkZHJlc3NlcyBhcyB0ZXh0IHdpdGhp biB0aGVpcgogICBibG9jay10eXBlLXNwZWNpZmljIGRhdGEgc2VjdGlvbi4gIFRoZXJlIGlz IG5vIHJlc3RyaWN0aW9uIG9uIHdoZXJlCiAgIG9yIGhvdyB0aGVzZSBhcmUgc3RvcmVkLgoK ICAgQSBibG9jayBNVVNUIE5PVCBjb250YWluIHJlZmVyZW5jZXMgaW4gaXRzIGJsb2NrLXR5 cGUtc3BlY2lmaWMgZGF0YQogICBzZWN0aW9uCgoKCgoKCgoKCgoKCgpMb3ZlbGwgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDEsIDIwMDcgICAgICAgICAgICAgICAgW1Bh Z2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVJRCByZWZlcmVuY2VzICAg ICAgICAgICAgICAgICAgIE1hcmNoIDIwMDcKCgozLiAgRGljdGlvbmFyeSBSZXZpc2lvbgoK ICAgQnVuZGxlIG5vZGVzIE1VU1Qgc3VwcG9ydCB0aGUgRUlEIHJlZmVyZW5jZSBzY2hlbWUg ZGVzY3JpYmVkIGFib3ZlIGluCiAgIFNlY3Rpb24gMi4xLgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkxvdmVsbCAgICAgICAgICAgICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgRUlEIHJlZmVyZW5jZXMgICAgICAgICAgICAgICAg ICAgTWFyY2ggMjAwNwoKCjQuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBOb25lIGF0IHRo aXMgdGltZS4gIElmIHRoZSBidW5kbGUgcHJvdG9jb2wgYmVjb21lcyBhIHN0YW5kYXJkcyB0 cmFjawogICBwcm90b2NvbCwgdGhlbiB3ZSBtYXkgd2FudCB0byBjb25zaWRlciBoYXZpbmcg SUFOQSBlc3RhYmxpc2ggYQogICByZWdpc3RlciBvZiBibG9jayB0eXBlcywgYW5kIGluIHBh cnRpY3VsYXIgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbiBhCiAgIHNlcGFyYXRlIHJlZ2lzdGVy IG9mIGJsb2NrIGZvcm1hdHMuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCkxvdmVsbCAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMSwg MjAwNyAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgRUlEIHJlZmVyZW5jZXMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNwoKCjUu ICBSZWZlcmVuY2VzCgo1LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgWzFdICBCcmFk bmVyLCBTLiBhbmQgSi4gUmV5bm9sZHMsICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRv CiAgICAgICAgSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgUkZDIDIxMTksIE9jdG9i ZXIgMTk5Ny4KCiAgIFsyXSAgU2NvdHQsIEsuLCAiQnVuZGxlIFByb3RvY29sIFNwZWNpZmlj YXRpb24iLAogICAgICAgIGRyYWZ0LWlydGYtZHRucmctYnVuZGxlLXNwZWMtMDYudHh0ICwg QXVndXN0IDIwMDYuCgogICBbM10gIFN5bWluZ3RvbiwgUy4sIEZhcnJlbGwsIFMuLCBXZWlz cywgSC4sIGFuZCBQLiBMb3ZlbGwsICJCdW5kbGUKICAgICAgICBTZWN1cml0eSBQcm90b2Nv bCBTcGVjaWZpY2F0aW9uIiwKICAgICAgICBkcmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1zZWN1 cml0eS0wMy50eHQgLCBNYXJjaCAyMDA3LgoKNS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNl cwoKICAgWzRdICBDZXJmLCBWLiwgIkRlbGF5LVRvbGVyYW50IE5ldHdvcmsgQXJjaGl0ZWN0 dXJlIiwKICAgICAgICBkcmFmdC1pcnRmLWR0bnJnLWFyY2gtMDcudHh0ICwgT2N0b2JlciAy MDA2LAogICAgICAgIDxkcmFmdC1pcnRmLWR0bnJnLWFyY2gtMDcudHh0Pi4KCiAgIFs1XSAg RmFycmVsbCwgUy4sIFN5bWluZ3RvbiwgUy4sIGFuZCBILiBXZWlzcywgIkRlbGF5LVRvbGVy YW50CiAgICAgICAgTmV0d29yayBTZWN1cml0eSBPdmVydmlldyIsCiAgICAgICAgZHJhZnQt aXJ0Zi1kdG5yZy1zZWMtb3ZlcnZpZXctMDIudHh0ICwgT2N0b2JlciAyMDA2LgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKTG92ZWxsICAgICAgICAgICAgICAgICAgIEV4cGlyZXMg T2N0b2JlciAxLCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICBFSUQgcmVmZXJlbmNlcyAgICAgICAgICAgICAgICAgICBNYXJj aCAyMDA3CgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgUGV0ZXIgTG92ZWxsCiAgIFNQQVJUQSwg SW5jLgogICA3MTEwIFNhbXVlbCBNb3JzZSBEcml2ZQogICBDb2x1bWJpYSwgTUQgIDIxMDQ2 CiAgIFVTCgogICBQaG9uZTogKzEtNDQzLTQzMC04MDUyCiAgIEVtYWlsOiBwZXRlci5sb3Zl bGxAc3BhcnRhLmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CkxvdmVsbCAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMSwgMjAwNyAgICAg ICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgRUlE IHJlZmVyZW5jZXMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNwoKCkZ1bGwgQ29weXJp Z2h0IFN0YXRlbWVudAoKICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNyku CgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMg YW5kIHJlc3RyaWN0aW9ucwogICBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFz IHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycwogICByZXRhaW4gYWxsIHRoZWlyIHJp Z2h0cy4KCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbgogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09O VFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMKICAgT1IgSVMg U1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwgVEhFIElFVEYg VFJVU1QgQU5ECiAgIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NM QUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTCiAgIE9SIElNUExJRUQsIElOQ0xVRElORyBC VVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRgogICBUSEUg SU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5Z IElNUExJRUQKICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBG T1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCgoKSW50ZWxsZWN0dWFsIFByb3BlcnR5CgogICBU aGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNj b3BlIG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJp Z2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVt ZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlz IGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3Vj aCByaWdodHMKICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMg aXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9y dCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbgogICBvbiB0aGUg cHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2Fu IGJlCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgQ29waWVzIG9mIElQUiBk aXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkKICAgYXNz dXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3Vs dCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9y IHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YKICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMg YnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMKICAgc3BlY2lmaWNhdGlvbiBjYW4g YmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0CiAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoKICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50 ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQogICBjb3B5cmln aHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0 YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJl cXVpcmVkIHRvIGltcGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3Mg dGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3JnLgoK CkFja25vd2xlZGdtZW50CgogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlv biBpcyBwcm92aWRlZCBieSB0aGUgSUVURgogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFj dGl2aXR5IChJQVNBKS4KCgoKCgpMb3ZlbGwgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBP Y3RvYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxMF0KDAo= --==_20070330203409.1848455294-1_==-- Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2UI47Y15891 for ; Fri, 30 Mar 2007 10:04:07 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 4A80368035 for ; Fri, 30 Mar 2007 19:04:01 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A024A1473EF; Fri, 30 Mar 2007 19:04:01 +0100 Received: from [134.226.62.161] (cswireless62-161.cs.tcd.ie [134.226.62.161]) by imx2.tcd.ie (Postfix) with ESMTP id 3DA6E68035 for ; Fri, 30 Mar 2007 19:04:01 +0100 (IST) Message-ID: <460D5169.8060201@cs.tcd.ie> Date: Fri, 30 Mar 2007 19:05:29 +0100 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] dicsussion draft for dtn-interest References: <20070330174705.330139065@127.0.0.1> In-Reply-To: <20070330174705.330139065@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A124A1473EF X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.69.2) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Ok, so to be sure that we all want to do this, can you send a message under this thread in the next week saying: +1 I like this, do it -1 I don't want to do that If (as I suspect) we do want to include the change (all the implementers seem to anyway as far as we know), then Keith will issue a revised I-D at the end of the next week containing the change. S. PS: This is being a bit formal for an IRTF RG, but since we're 1/2 way through the IRSG review for this I think its worth doing this way. Peter Lovell wrote: > Sending for review on wider dtn-interest list ... > > > On Fri, Mar 30, 2007, Stephen Farrell wrote: > >> My summary from the call just now:- >> >> 1. We seem to have consensus to make Pete's change >> 2. Pete to send details of the change to dtn-interest saying its >> planned to be in the next BP spec >> 3. Me to start a 1-week timer on that so's everyone has a chance >> to see it >> 4. Everyone to say (on dtn-interest) that they like the change >> 5. Keith to issue a new BP-spec at the end of the week (so long >> as no-one convinces us otherwise on the list) >> 6. Pete to issue the security spec referring to #5 >> 7. Me to bribe^H^H^H^H^Htalk to the IRSG reviewers about the >> change:-) >> 8. No more changes. >> >> S. > > Following up on Stephen's meeting summary, here's a "mini I-D" > describing the proposal. It has been revised slightly from an earlier > one some of you have seen, reflecting a requested change in field > ordering (optional field moved before "length"), clarification that the > references are pairs of SDNVs, and a textual change in the way bit > numbering is described. > > I think this is the right solution and will allow extension to > effectively use the bundle dictionary but with minimal impact elsewhere. > A few significant points:- > > - it's optional for extensions. They don't have to use it > - the new BP-spec will describe protocol version 5, so all core > implementations will have to change anyhow (there's no interoperability > between versions 4 and 5 because of changes in the primary block) > > I had planned to issue the new draft of Bundle Security Protocol after > the meeting but will delay that until the comment period is finished > next week. If anyone would like a copy I can send the almost-final > version (pending BP-spec) off-list. > > Regards.....Peter Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2UHlCY15764 for ; Fri, 30 Mar 2007 09:47:13 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2UHl9p8010526 for ; Fri, 30 Mar 2007 12:47:09 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2UHl8L6002499 for ; Fri, 30 Mar 2007 12:47:08 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 13:47:06 -0400 From: "Peter Lovell" To: "dtn interest" Date: Fri, 30 Mar 2007 13:47:05 -0400 Message-Id: <20070330174705.330139065@127.0.0.1> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==_20070330174705.330139065-1_==" X-OriginalArrivalTime: 30 Mar 2007 17:47:06.0366 (UTC) FILETIME=[6EBA21E0:01C772F3] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Fri, 30 Mar 2007 12:47:09 -0500 (CDT) Subject: [dtn-interest] dicsussion draft for dtn-interest Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: --==_20070330174705.330139065-1_== Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sending for review on wider dtn-interest list ... On Fri, Mar 30, 2007, Stephen Farrell wrote: > >My summary from the call just now:- > >1. We seem to have consensus to make Pete's change >2. Pete to send details of the change to dtn-interest saying its > planned to be in the next BP spec >3. Me to start a 1-week timer on that so's everyone has a chance > to see it >4. Everyone to say (on dtn-interest) that they like the change >5. Keith to issue a new BP-spec at the end of the week (so long > as no-one convinces us otherwise on the list) >6. Pete to issue the security spec referring to #5 >7. Me to bribe^H^H^H^H^Htalk to the IRSG reviewers about the > change:-) >8. No more changes. > >S. Following up on Stephen's meeting summary, here's a "mini I-D" describing the proposal. It has been revised slightly from an earlier one some of you have seen, reflecting a requested change in field ordering (optional field moved before "length"), clarification that the references are pairs of SDNVs, and a textual change in the way bit numbering is described. I think this is the right solution and will allow extension to effectively use the bundle dictionary but with minimal impact elsewhere. A few significant points:- - it's optional for extensions. They don't have to use it - the new BP-spec will describe protocol version 5, so all core implementations will have to change anyhow (there's no interoperability between versions 4 and 5 because of changes in the primary block) I had planned to issue the new draft of Bundle Security Protocol after the meeting but will delay that until the comment period is finished next week. If anyone would like a copy I can send the almost-final version (pending BP-spec) off-list. Regards.....Peter --==_20070330174705.330139065-1_== Content-Type: text/plain; name="draft-irtf-dtnrg-bundle-EIDrefs-01.txt"; x-mac-type="00000000"; x-mac-creator="00000000" Content-Disposition: attachment Content-Transfer-Encoding: base64 CgoKRFROIFJlc2VhcmNoIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUC4gTG92ZWxsCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNQQVJUQSwgSW5jLgpFeHBpcmVzOiBPY3Rv YmVyIDEsIDIwMDcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMzAs IDIwMDcKCgogICAgICAgICAgICAgICAgICAgIERUTiBFSUQgUmVmZXJlbmNlcyBTcGVjaWZp Y2F0aW9uCiAgICAgICAgICAgICAgICAgICBkcmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1FSURy ZWZzLTAxCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50 ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBwbGlj YWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMg YXdhcmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdo aWNoIGhlIG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBh Y2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAg IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMu ICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBv ZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxpc3Qgb2Yg SW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdAog ICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiBPY3RvYmVyIDEsIDIwMDcuCgpDb3B5cmlnaHQgTm90aWNl CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3KS4KCgoKCgoKCgoKCgoK CgoKTG92ZWxsICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxLCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBF SUQgcmVmZXJlbmNlcyAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDA3CgoKQWJzdHJhY3QK CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgY29udmVudGlvbiBmb3Igc3RvcmluZyBy ZWZlcmVuY2VzIHRvIERlbGF5LQogICBUb2xlcmFudCBOZXR3b3JraW5nIChEVE4pIEJ1bmRs ZSBQcm90b2NvbCAoQlApIGVuZHBvaW50IGlkZW50aWZpZXJzCiAgIFtFSURzXSB3aXRoaW4g ZXh0ZW5zaW9uIGJsb2NrcyBvZiBidW5kbGVzLgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAx LiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDMKICAgMi4gIFN0b3JhZ2UgQ29udmVudGlvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgICAgMi4xLiAgRUlEIFJlZmVy ZW5jZSBMaXN0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQog ICAgIDIuMi4gIFByaXZhdGUgRUlEIFJlZmVyZW5jZSBTdG9yYWdlICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDYKICAgMy4gIERpY3Rpb25hcnkgUmV2aXNpb24gIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgIDQuICBJQU5BIENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg OAogICA1LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICA1LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgNS4yLiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOQogICBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBD b3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgpMb3ZlbGwgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBP Y3RvYmVyIDEsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgIEVJRCByZWZlcmVuY2VzICAgICAgICAgICAgICAgICAgIE1hcmNo IDIwMDcKCgoxLiAgSW50cm9kdWN0aW9uCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBp biB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gWzFdLgoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIG9wdGlvbmFsIG1ldGhvZCBm b3IgZXh0ZW5zaW9ucyB0byB0aGUgRFROCiAgIGJ1bmRsZSBwcm90b2NvbCBbMl0gdG8gc3Rv cmUgcmVmZXJlbmNlcyB0byBlbmRwb2ludCBhZGRyZXNzZXMgaW4gdGhlCiAgIGJ1bmRsZSBk aWN0aW9uYXJ5LiAgRUlEcyBhbmQgdGhlIHJlZmVyZW5jZSBmb3JtYXQgYXJlIGRlc2NyaWJl ZCBpbgogICBbMl0gc2VjdGlvbiAzLjUuCgogICBUaGUgcHJpbWFyeSBibG9jayBvZiBlYWNo IGJ1bmRsZSBjb250YWlucyBhICJkaWN0aW9uYXJ5IiBieXRlIGFycmF5LgogICBUaGUgdGV4 dCB2YWx1ZXMgb2YgdGhlIGVuZHBvaW50IGlkZW50aWZpZXJzIGluIHRoZSBwcmltYXJ5IGJs b2NrLAogICBzdWNoIGFzIHNvdXJjZSBhbmQgZGVzdGluYXRpb24sIGFyZSBzdG9yZWQgaW4g dGhlIGRpY3Rpb25hcnkgYW5kCiAgIHJlZmVyZW5jZXMgdG8gdGhlbSBhcmUgc3RvcmVkIGlu IHNwZWNpZmljIHBsYWNlcyBpbiB0aGUgcHJpbWFyeQogICBibG9jay4KCiAgIERUTiBwcm90 b2NvbCBleHRlbnNpb25zIG1heSBhbHNvIGFkZCBlbmRwb2ludCBpZGVudGlmaWVycyB0byB0 aGUKICAgZGljdGlvbmFyeSBhbmQgc3RvcmUgcmVmZXJlbmNlcyB3aXRoaW4gdGhlaXIgZXh0 ZW5zaW9uIGJsb2Nrcy4KCiAgIFRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgYXQgZWFjaCBu b2RlIG1heSB3aXNoIHRvIHJlbW92ZSBhbnkKICAgZGljdGlvbmFyeSBlbnRyaWVzIGZvciB3 aGljaCByZWZlcmVuY2VzIG5vIGxvbmdlciBleGlzdCBhbmQsIHRvIGRvCiAgIHNvLCBtdXN0 IGJlIGFibGUgdG8gbG9jYXRlIGFsbCBleGlzdGluZyBFSUQgcmVmZXJlbmNlcyBpbiBhIGJ1 bmRsZS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkxvdmVsbCAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIE9jdG9iZXIgMSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgRUlEIHJlZmVyZW5jZXMgICAgICAgICAg ICAgICAgICAgTWFyY2ggMjAwNwoKCjIuICBTdG9yYWdlIENvbnZlbnRpb24KCiAgIEFsbCBl eHRlbnNpb24gYmxvY2tzIHVzZXMgdGhlIENhbm9uaWNhbCBCdW5kbGUgQmxvY2sgRm9ybWF0 IGFzCiAgIGRlZmluZWQgaW4gdGhlIEJ1bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uLiAg RWFjaCBpcyBjb21wcmlzZWQgb2YKICAgdGhlIGZvbGxvd2luZyBlbGVtZW50czoKCiAgICAg IC0gQmxvY2sgdHlwZSBjb2RlCgogICAgICAtIEJsb2NrIHByb2Nlc3NpbmcgY29udHJvbCBm bGFncwoKICAgICAgLSBCbG9jayBFSUQgcmVmZXJlbmNlIGxpc3QgKG9wdGlvbmFsKQoKICAg ICAgLSBCbG9jayBkYXRhIGxlbmd0aAoKICAgICAgLSBCbG9jay10eXBlLXNwZWNpZmljIGRh dGEgZmllbGRzCgogICBUaGUgdHlwZSwgZmxhZ3MsIGxlbmd0aCBhbmQgbGlzdCBmaWVsZHMg YXJlIGNvbW1vbiB0byBhbGwgZXh0ZW5zaW9uCiAgIGJsb2NrcyBhbmQgYXJlIGtub3duIGNv bGxlY3RpdmVseSBhcyB0aGUgInByZWFtYmxlIi4KCgogICArLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgIHx0eXBlICAgICAgIHwgICAgICBm bGFncyAoU0ROVikgICAgICAgICAgICAgICAgIHwKICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKwogICB8ICAgICAgICAgICAgbGVuZ3RoICAo U0ROVikgICAgICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0t LSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKICAgfCAgYmxvY2sgYm9keSBkYXRhICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgID0gICAgIChjb250aW51ZXMgLi4uICkgICAg ICAgICAgICAgICAgICAgICAgICAgID0KICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tKwogICB8ICBibG9jayBib2R5IGRhdGEgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t LS0tLS0tLSstLS0tLS0tLS0tLSsKCiAgIEdlbmVyYWwgYmxvY2sgbGF5b3V0CgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMQoKICAgTm90ZTogdGhpcyBzYW1l IGxheW91dCBhcHBsaWVzIGFsc28gdG8gdGhlIHBheWxvYWQgYmxvY2suICBIb3dldmVyLAog ICB0aGUgYm9keSBkYXRhIGZpZWxkIGNvbnRhaW5zIG9ubHkgdGhlIHBheWxvYWQgYW5kIG5v IEVJRCByZWZlcmVuY2VzCiAgIHNvIHRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBhcHBs eS4KCiAgIEVJRCByZWZlcmVuY2VzIG1heSBiZSBzdG9yZWQgaW4gYSBibG9jayBpbiB0d28g d2F5czotCgogICAgICAtIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGJsb2NrIGluIHRoZSBF SUQgcmVmZXJlbmNlIGxpc3QKCiAgICAgIC0gc29tZXdoZXJlIHByaXZhdGUgd2l0aGluIHRo ZSBibG9jay10eXBlLXNwZWNpZmljIGRhdGEgZmllbGRzCgoKCgoKCkxvdmVsbCAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMSwgMjAwNyAgICAgICAgICAgICAgICBbUGFn ZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgRUlEIHJlZmVyZW5jZXMgICAg ICAgICAgICAgICAgICAgTWFyY2ggMjAwNwoKCjIuMS4gIEVJRCBSZWZlcmVuY2UgTGlzdAoK ICAgVGhlIEVJRCByZWZlcmVuY2UgbGlzdCBpcyBhIGNvbXBvc2l0ZSBmaWVsZCBhbmQgbWF5 IG9wdGlvbmFsbHkgYmUKICAgcHJlc2VudCBpbiBhbnkgZXh0ZW5zaW9uIGJsb2NrLiAgSXQg Y29uc2lzdHMgb2YgYSBjb3VudCBmaWVsZAogICBmb2xsb3dlZCBieSB0aGF0IG51bWJlciBv ZiByZWZlcmVuY2VzLiAgVGhlIGNvdW50IGlzIGFuIFNETlYgYXMKICAgZGVzY3JpYmVkIGlu IFsyXSBzZWN0aW9uIDMuMS4gIEVhY2ggcmVmZXJlbmNlIGlzIGEgb3JkZXJlZCBwYWlyIG9m CiAgIFNETlZzIChjb21wcmVzc2VkIDE2LWJpdCB1bnNpZ25lZCBpbnRlZ2VycyksIGFzIGRl c2NyaWJlZCBpbiBbMl0KICAgc2VjdGlvbiAzLjUsIGNvbnRhaW5pbmc6CgogICAgICAtIHRo ZSBvZmZzZXQsIHdpdGhpbiB0aGUgZGljdGlvbmFyeSwgb2YgdGhlIGZpcnN0IGNoYXJhY3Rl ciBvZiB0aGUKICAgICAgcmVmZXJlbmNlZCBlbmRwb2ludCBJRCdzIHNjaGVtZSBuYW1lCgog ICAgICAtIHRoZSBvZmZzZXQsIHdpdGhpbiB0aGUgZGljdGlvbmFyeSwgb2YgdGhlIGZpcnN0 IGNoYXJhY3RlciBvZiB0aGUKICAgICAgcmVmZXJlbmNlZCBlbmRwb2ludCBJRCdzIFNTUAoK ICAgUHJlc2VuY2Ugb2YgdGhlIGZpZWxkIGlzIGluZGljYXRlZCBieSB0aGUgc2V0dGluZyBv ZiBiaXQgMHg0MCBvZiB0aGUKICAgYmxvY2sgcHJvY2Vzc2luZyBjb250cm9sIGZsYWdzLgoK ICAgSWYgYml0IDB4NDAgaXMgbm90IHNldCB0aGVuIHRoZXJlIGlzIG5vIEVJRCByZWZlcmVu Y2UgZmllbGQsIGFuZAogICBuZWl0aGVyIGNvdW50IG5vciByZWZlcmVuY2VzIG1heSBhcHBl YXIuCgoKICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tKwogICB8dHlwZSAgICAgICB8ICAgICAgZmxhZ3MgKFNETlYpICAgICAgICAgICAgICAg ICB8CiAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0t LSsKICAgfCAgICAgICAgICAgRUlEIHJlZmVyZW5jZSBjb3VudCAoU0ROVikgICAgICAgICAg fAogICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0r CiAgIHwgICAgICAgICAgICBsZW5ndGggIChTRE5WKSAgICAgICAgICAgICAgICAgICAgIHwK ICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKwog ICB8ICByZWZfc2NoZW1lXzEgKFNETlYpICB8ICAgIHJlZl9zc3BfMSAoU0ROVikgICB8CiAg ICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKICAg fCAgcmVmX3NjaGVtZV8yIChTRE5WKSAgfCAgICByZWZfc3NwXzIgKFNETlYpICAgfAogICAr LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgIHwg IGJsb2NrLXR5cGUtc3BlY2lmaWMgZGF0YSAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKwogICA9ICAg IChjb250aW51ZXMgLi4uICkgICAgICAgICAgICAgICAgICAgICAgICAgICA9CiAgICstLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKICAgfCAgYmxv Y2stdHlwZS1zcGVjaWZpYyBkYXRhICAgICAgICAgICAgICAgICAgICAgfAogICArLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCgogICBBIHNhbXBs ZSBibG9jayBsYXlvdXQgc2hvd2luZyB0d28gRUlEIHJlZmVyZW5jZXMKCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyCgoKCgoKCgoKTG92ZWxsICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxLCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdl IDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBFSUQgcmVmZXJlbmNlcyAgICAg ICAgICAgICAgICAgICBNYXJjaCAyMDA3CgoKMi4yLiAgUHJpdmF0ZSBFSUQgUmVmZXJlbmNl IFN0b3JhZ2UKCiAgIEV4dGVuc2lvbiBibG9ja3MgbWF5IGNvbnRhaW4gRUlEIHJlZmVyZW5j ZXMgd2l0aGluIHRoZWlyIGJsb2NrLXR5cGUtCiAgIHNwZWNpZmljIGRhdGEgc2VjdGlvbi4g IFRoZXJlIGlzIG5vIHJlc3RyaWN0aW9uIG9uIHdoZXJlIG9yIGhvdyB0aGVzZQogICBhcmUg c3RvcmVkLgoKICAgSWYgYSBibG9jayBkb2VzIGNvbnRhaW4gcmVmZXJlbmNlcyBpbiBpdHMg YmxvY2stdHlwZS1zcGVjaWZpYyBkYXRhCiAgIHNlY3Rpb24sIHRoZW4gYXQgbGVhc3Qgb25l IG9mIHRoZSBmb2xsb3dpbmcgZmxhZ3MgTVVTVCBhbHNvIGJlIHNldDoKCiAgICAgIDB4MDQg LSBEaXNjYXJkIGJ1bmRsZSBpZiBibG9jayBjYW4ndCBiZSBwcm9jZXNzZWQKCiAgICAgIDB4 MTAgLSBEaXNjYXJkIGJsb2NrIGlmIGJsb2NrIGNhbid0IGJlIHByb2Nlc3NlZAoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpMb3ZlbGwgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDEsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVJRCByZWZlcmVuY2VzICAgICAgICAgICAg ICAgICAgIE1hcmNoIDIwMDcKCgozLiAgRGljdGlvbmFyeSBSZXZpc2lvbgoKICAgQnVuZGxl IG5vZGVzIHdoaWNoIHBlcmZvcm0gZGljdGlvbmFyeSByZXZpc2lvbiwgYXMgZGVzY3JpYmVk IGluIFsyXQogICBzZWN0aW9uIDMuOCwgTVVTVCBzdXBwb3J0IHRoZSBFSUQgcmVmZXJlbmNl IHNjaGVtZSBkZXNjcmliZWQgYWJvdmUgaW4KICAgU2VjdGlvbiAyLjEuCgogICBBIG5vZGUg d2hpY2ggZG9lcyBub3Qgc3VwcG9ydCB0aGUgRUlEIHJlZmVyZW5jZSBzY2hlbWUgbWF5IGFk ZCBpdGVtcwogICB0byBpdHMgZGljdGlvbmFyeSBidXQgTVVTVCBOT1QgcmV2aXNlIGV4aXN0 aW5nIGVudHJpZXMuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpMb3ZlbGwgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDEsIDIwMDcgICAg ICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVJ RCByZWZlcmVuY2VzICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDcKCgo0LiAgSUFOQSBD b25zaWRlcmF0aW9ucwoKICAgTm9uZSBhdCB0aGlzIHRpbWUuICBJZiB0aGUgYnVuZGxlIHBy b3RvY29sIGJlY29tZXMgYSBzdGFuZGFyZHMgdHJhY2sKICAgcHJvdG9jb2wsIHRoZW4gd2Ug bWF5IHdhbnQgdG8gY29uc2lkZXIgaGF2aW5nIElBTkEgZXN0YWJsaXNoIGEKICAgcmVnaXN0 ZXIgb2YgYmxvY2sgdHlwZXMsIGFuZCBpbiBwYXJ0aWN1bGFyIGZvciB0aGlzIHNwZWNpZmlj YXRpb24gYQogICBzZXBhcmF0ZSByZWdpc3RlciBvZiBibG9jayBmb3JtYXRzLgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpMb3ZlbGwgICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDEsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2Ug OF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVJRCByZWZlcmVuY2VzICAgICAg ICAgICAgICAgICAgIE1hcmNoIDIwMDcKCgo1LiAgUmVmZXJlbmNlcwoKNS4xLiAgTm9ybWF0 aXZlIFJlZmVyZW5jZXMKCiAgIFsxXSAgQnJhZG5lciwgUy4gYW5kIEouIFJleW5vbGRzLCAi S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0bwogICAgICAgIEluZGljYXRlIFJlcXVpcmVt ZW50IExldmVscyIsIFJGQyAyMTE5LCBPY3RvYmVyIDE5OTcuCgogICBbMl0gIFNjb3R0LCBL LiwgIkJ1bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIiwKICAgICAgICBkcmFmdC1pcnRm LWR0bnJnLWJ1bmRsZS1zcGVjLTA2LnR4dCAsIEF1Z3VzdCAyMDA2LgoKICAgWzNdICBTeW1p bmd0b24sIFMuLCBGYXJyZWxsLCBTLiwgV2Vpc3MsIEguLCBhbmQgUC4gTG92ZWxsLCAiQnVu ZGxlCiAgICAgICAgU2VjdXJpdHkgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiIsCiAgICAgICAg ZHJhZnQtaXJ0Zi1kdG5yZy1idW5kbGUtc2VjdXJpdHktMDMudHh0ICwgTWFyY2ggMjAwNy4K CjUuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFs0XSAgQ2VyZiwgVi4sICJEZWxh eS1Ub2xlcmFudCBOZXR3b3JrIEFyY2hpdGVjdHVyZSIsCiAgICAgICAgZHJhZnQtaXJ0Zi1k dG5yZy1hcmNoLTA3LnR4dCAsIE9jdG9iZXIgMjAwNiwKICAgICAgICA8ZHJhZnQtaXJ0Zi1k dG5yZy1hcmNoLTA3LnR4dD4uCgogICBbNV0gIEZhcnJlbGwsIFMuLCBTeW1pbmd0b24sIFMu LCBhbmQgSC4gV2Vpc3MsICJEZWxheS1Ub2xlcmFudAogICAgICAgIE5ldHdvcmsgU2VjdXJp dHkgT3ZlcnZpZXciLAogICAgICAgIGRyYWZ0LWlydGYtZHRucmctc2VjLW92ZXJ2aWV3LTAy LnR4dCAsIE9jdG9iZXIgMjAwNi4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkxvdmVs bCAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMSwgMjAwNyAgICAgICAgICAg ICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgRUlEIHJlZmVy ZW5jZXMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNwoKCkF1dGhvcidzIEFkZHJlc3MK CiAgIFBldGVyIExvdmVsbAogICBTUEFSVEEsIEluYy4KICAgNzExMCBTYW11ZWwgTW9yc2Ug RHJpdmUKICAgQ29sdW1iaWEsIE1EICAyMTA0NgogICBVUwoKICAgUGhvbmU6ICsxLTQ0My00 MzAtODA1MgogICBFbWFpbDogcGV0ZXIubG92ZWxsQHNwYXJ0YS5jb20KCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpMb3ZlbGwgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBPY3RvYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVJRCByZWZlcmVuY2VzICAgICAgICAgICAgICAg ICAgIE1hcmNoIDIwMDcKCgpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQKCiAgIENvcHlyaWdo dCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJq ZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMKICAgY29udGFp bmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1 dGhvcnMKICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuCgogICBUaGlzIGRvY3VtZW50IGFu ZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4K ICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9O IEhFL1NIRSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhF IElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORAogICBUSEUgSU5URVJORVQg RU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVT UwogICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJS QU5UWSBUSEFUIFRIRSBVU0UgT0YKICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5P VCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVECiAgIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgoK CkludGVsbGVjdHVhbCBQcm9wZXJ0eQoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24g cmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkKICAgSW50ZWxsZWN0dWFs IFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVk IHRvCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVj aG5vbG9neSBkZXNjcmliZWQgaW4KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRv IHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1pZ2h0 IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcwog ICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmln aHRzLiAgSW5mb3JtYXRpb24KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRv IHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQogICBmb3VuZCBpbiBCQ1AgNzggYW5k IEJDUCA3OS4KCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVU RiBTZWNyZXRhcmlhdCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUg bWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRv IG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9m CiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBv ZiB0aGlzCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYg b24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4K CiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8g aXRzIGF0dGVudGlvbiBhbnkKICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBw bGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292 ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhp cyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVU RiBhdAogICBpZXRmLWlwckBpZXRmLm9yZy4KCgpBY2tub3dsZWRnbWVudAoKICAgRnVuZGlu ZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYK ICAgQWRtaW5pc3RyYXRpdmUgU3VwcG9ydCBBY3Rpdml0eSAoSUFTQSkuCgoKCgoKTG92ZWxs ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxLCAyMDA3ICAgICAgICAgICAg ICAgW1BhZ2UgMTFdCgwK --==_20070330174705.330139065-1_==-- Received: from smtp.unilim.fr (mail.unilim.fr [164.81.1.45]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2UFkvY14932 for ; Fri, 30 Mar 2007 07:46:57 -0800 Received: from [164.81.60.82] (sauveron-port.msi.unilim.fr [164.81.60.82]) (authenticated bits=0) by smtp.unilim.fr (8.13.1/8.13.1) with ESMTP id l2UFkrZH019841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Mar 2007 17:46:54 +0200 Message-ID: <460D30EE.4070907@xlim.fr> Date: Fri, 30 Mar 2007 17:46:54 +0200 From: Damien Sauveron User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Univ-Limoges-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (smtp.unilim.fr [164.81.1.45]); Fri, 30 Mar 2007 17:46:54 +0200 (CEST) X-Univ-Limoges-MailScanner-Information: Serveur Anti-virus Please contact the SCI, Univ. of Limoges, for more information X-Univ-Limoges-MailScanner: Found to be clean X-Univ-Limoges-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (cached, score=-101.785, requis 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_40 -0.18, MR_NOT_ATTRIBUTED_IP 0.20, SMTP_AUTH -100.00) X-Univ-Limoges-MailScanner-Envelope-From: damien.sauveron@xlim.fr Subject: [dtn-interest] [WISTP'2007] 4 Grants for Young Researchers sponsored by Nokia Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: ******************************************************************* We apologize in advance if you receive multiple copies of this CFP. Please disseminate it to your colleagues that could be interested. ******************************************************************* Workshop in Information Security Theory and Practices 2007: Smart Cards, Mobile and Ubiquitous Computing Systems && A networking meeting to discuss proposals for the EU FP7 Heraklion, Crete, Greece May 8-11, 2007 Workshop URL: http://wistp2007.xlim.fr/ Preliminary Program: http://wistp2007.xlim.fr/CFP.html#Preliminary_program ******************************************************************* 4 Grants for Young Researchers (PhD students or in postdoctoral position) are sponsored by *Nokia*. These grants include accommodation costs (3 nights in the hotel hosting the workshop) and registration fees for the Workshop and the FP7 meeting. The travel is NOT funded. ******************************************************************* Grant application: - Selection will be done by the Organizers and Chairs based on a short CV (1 page maximum), a motivation letter (1 page maximum) and if possible a recommendation letter - Send these documents to wistp2007sec@xlim.fr before the deadline - deadline: 6th of April 2007 - notification of acceptance: 10th of April 2007 The selected applicants will provide one week maximum after the events a short report (5 to 10 pages) written in english to summarize the scientific and organizational aspects (to be discussed with the organizers later). ******************************************************* We hope you will be interested by this event. For further inquiries, please contact the secretariat at wistp2007sec@xlim.fr Best regards, -- Damien Sauveron Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2TKEeY01588; Thu, 29 Mar 2007 12:14:40 -0800 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id B07F64FEFD; Thu, 29 Mar 2007 23:14:38 +0300 (EET DST) Message-ID: <460C1E2E.9010906@netlab.hut.fi> Date: Thu, 29 Mar 2007 22:14:38 +0200 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DTN dev , DTN Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [dtn-interest] Call for Papers: CHANTS 2007 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Second Workshop on Challenged Networks (CHANTS) 2007 ==================================================== Co-located with Mobicom 2007, 14 September 2007, Montreal, QC, Canada http://www.netlab.tkk.fi/chants-2007 Challenged networks are characterized by a heterogeneous mix of nodes and widely varying network conditions. Nodes in today's challenged networks often include mobile nodes, space-based nodes, sensor/actuator nodes and other devices. Performance of the network paths interconnecting such nodes can be highly varying in terms of bandwidth, latency, disruption characteristics and security requirements. Conventional Internet access in performance-limited environments such as developing countries can also be regarded as challenged networks as can be ad-hoc communication between personal devices. The Internet protocol architecture suffers some problems when used in a challenged network setting. For example, when disconnection and reconnection is common or link performance is highly variable or extreme, one or more of the traditional Internet protocols do not work well. In this workshop following CHANTS 2006 and WDTN 2005, we wish to explore ongoing efforts in dealing with physical networks that operate significantly differently from wired, connected networks and the protocol architectures and algorithms used to deal with such situations. Techniques for making applications tolerant to disruptions and/or high delays are also in scope. We specifically solicit papers in the following areas: * Characterization of performance-challenged networks e.g. network measurements * Networking systems operating over unusual/challenged networks * Protocol design and evaluation of operations over challenged networks * System architecture and design for challenged networks * Applications in challenged networks * Robust network application design and implementation techniques * Delay tolerant and disruption tolerant networks (DTN) * Configuration and management of challenged networks Submissions may include presentations of specific systems or performance measurements, as well as architectural papers addressing new concerns. Papers that bring out problems in the existing proposals for challenged networks or that report operational experience will be favored. Selected papers will be forward-looking, will describe their relationship to existing work, and will have impact and implications for ongoing or future research. We aim to accept approximately 12 papers, and to have a highly interactive workshop focusing on evolving this area of network research and continuing to build its community. In addition, we seek submission of demo proposals, also to be reviewed by the TPC. The demo proposals shall present recent practical results from the area of challenged networks. In exceptional cases, where live demos are simply not practical to present, poster or video presentations of practical results are acceptable, too. Paper Format and Submission --------------------------- Submitted papers must be no more than 8 pages long, two columns, with no characters in smaller than 10 point fonts, and must fit properly on US "Letter"-sized paper (8.5x11 inches). Margins must be of 1 inch on all edges (top, bottom, left, and right) of each page. Demo proposal abstracts (to be published as part of the proceedings) shall not be longer than 3 pages plus 1 page description of the precise setup and requirements. Paper submission will be handled via EDAS. Papers will be reviewed single blind. Paper submission URI: http://edas.info/5526 Important Dates --------------- Abstract Registration Deadline: 27 April 2007 Submission Deadline: 4 May 2007 Notification of Acceptance: 8 June 2007 Camera Ready Deadline: 27 June 2007 Workshop Date: 14 September 2007 Workshop Chairs --------------- Jörg Ott Helsinki University of Technology (TKK) Rajesh Krishnan BBN Technologies Steering Committee ------------------ Kevin Almeroth, University of California, Santa Barbara Mostafa Ammar, Georgia Institute of Technology Christophe Diot, Thomson Research, Paris, France Deborah Estrin, University of California, Los Angeles Kevin Fall, Intel Research Berkeley Jörg Ott, Helsinki University of Technology, Finland James Scott, Microsoft Research Cambridge, UK Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2SH92Y16173 for ; Wed, 28 Mar 2007 09:09:02 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 3638712EE80 for ; Wed, 28 Mar 2007 19:08:58 +0200 (CEST) Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25720-08 for ; Wed, 28 Mar 2007 19:08:57 +0200 (CEST) X-SMTP-Auth: no Received: from mx4.iit.cnr.it (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 41E9D12F259 for ; Wed, 28 Mar 2007 19:08:57 +0200 (CEST) Received: from bruno.iit.cnr.it (HELO [146.48.98.79]) (146.48.98.79) (smtp-auth username raffaele.bruno@iit.cnr.it, mechanism plain) by mx4.iit.cnr.it (qpsmtpd/0.32) with ESMTP; mer, 28 mar 2007 19:08:57 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <46DC8777-AA69-41EE-8583-682E08E37DA9@iit.cnr.it> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: dtn-interest@mailman.dtnrg.org From: Raffaele Bruno Date: Wed, 28 Mar 2007 19:08:57 +0200 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id l2SH92Y16173 Subject: [dtn-interest] =?WINDOWS-1252?Q?CFP_-_MASS-GHS=9207:_First_International_Worksh?= =?WINDOWS-1252?Q?op_on_Mobile_Ad_hoc_and_Sensor_Systems_for_Glob?= =?WINDOWS-1252?Q?al_and_Homeland_Security_?= Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Please accept our apologies if you receive multiple copies of this CFP. ---------------------------------------------------------------------- First International Workshop on Mobile Ad hoc and Sensor Systems for Global and Homeland Security (MASS-GHS’07) http://www.eecs.wsu.edu/~holder/mass-ghs07 Pisa, Italy – October 12, 2007 In conjunction with the 4th IEEE Conference on Mobile Ad-hoc and Sensor Systems (MASS’07) http://cnd.iit.cnr.it/mass2007/ ---------------------------------------------------------------------- THEME AND SCOPE The development, deployment and coordination of mobile ad hoc and sensor systems (MASS) has been studied for a number of years, and much of this research is beginning to transition into real solutions for a variety of domains. One domain that is ripe for MASS research and development is global and homeland security. Much of the security mission involves the monitoring of various environments (e.g., ports, borders, mass transit hubs, financial centers, power grids, the Internet) and the prediction and detection of threats to these environments. MASS represent a general solution to maintaining security in these environments. In this workshop we seek to bring together researchers and practitioners representing the state-of-the-art in MASS research and technology targeted toward the global and homeland security domain. Specific topics of interest include (but are not limited to) the following. All papers must have a clear, stated, and ideally tested application to global and homeland security. · Development of novel sensors and sensor systems for threat detection · Efficient and effective deployment of mobile devices and sensors · Heterogeneous systems for surveillance and threat detection · Novel architectures for use of MASS in Global and Homeland security · Secure and fault tolerant coordination and communication · Information fusion for prediction and detection of threats · Integration and registration of data from multiple sources · Effective decision-making in dynamic environments · Testing and evaluation of MASS for security · Simulation and modeling of MASS, environments, and scenarios · Simulation and modeling of threats and environments relevant to sensor response · Simulation and modeling of temporal threat events relevant to sensor response · Prototype models of secure environments · Secure smart environments · Disaster mitigation and emergency response PAPER SUBMISSIONS Papers are limited to eight (8) pages and must be formatted according to the main conference’s formatting requirements and submitted via the EDAS paper management system (see workshop website for details). Accepted papers will be published by IEEE in the MASS’07 conference proceedings. At least one author of each accepted paper must register for the conference at the full conference rate. Pending approval of a special issue of the Pervasive and Mobile Computing Journal, authors of high-quality papers presented at the workshop will be invited to submit extended versions for this special issue. IMPORTANT DATES Submission due: May 15, 2007 Acceptance Notification: July 15, 2007 Final Manuscript due: August 10, 2007 Workshop: October 12, 2007 WORKSHOP CO-CHAIRS Larry Holder, Washington State Univ., USA (holder@wsu.edu) Mohan Kumar, Univ. of Texas at Arlington, USA (mkumar@uta.edu) Raffaele Bruno, Institute for Informatics and Telematics, Italy (raffaele.bruno@iit.cnr.it) PROGRAM COMMITTEE Cesare Alippi, Politecnico di Milano, Italy Giuseppe Anastasi, Univ. of Pisa, Italy Paolo Bellavista, Univ. of Bologna, Italy Sajal Das, Univ. of Texas at Arlington, USA Silvia Giordano, Univ. of Applied Science, Switzerland Ajay Gupta, Western Michigan Univ., USA Jadwiga Indulska, Queensland Unversity, Australia William Kaiser, Univ. of California Los Angeles, USA Yonghe Liu, Univ. of Texas at Arlington, USA Murali Medidi, Washington State Univ., USA Sirisha Medidi, Washington State Univ., USA Scott Midkiff, Virginia Tech, USA Vinayak Naik, Univ. of California Los Angeles, USA Stephan Olariu, Old Dominion Univ., USA Leslie Owens, Booz Allen Hamilton, USA Marimuthu Palaniswami, Univ. of Melbourne, Australia Adrian Pearce, Univ. of Melbourne, Australia Marius Portmann, Univ. of Queensland, Australia Mohammad Rahimi, Univ. of California Los Angeles, USA Mallikarjun Shankar, Oak Ridge National Laboratory, USA Behrooz Shirazi, Washington State Univ., USA Mukesh Singhal, Univ. of Kentucky, USA --------------------------------------------------------- Raffaele Bruno, Ph.D., Researcher Pervasive Computing & Networking Lab. (PerLab) IIT Institute - Italian National Research Council (CNR) Via G. Moruzzi 1, 56124 Pisa, ITALY Tel.: +39 050 315 3078 (direct) Fax.: +39 050 315 2593 (institute) Email: raffaele.bruno@iit.cnr.it Website: bruno1.iit.cnr.it/~bruno/ Received: from mx1.grc.nasa.gov (mx1.grc.nasa.gov [128.156.11.68]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2SFfPY15590 for ; Wed, 28 Mar 2007 07:41:25 -0800 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id A3571C2A4 for ; Wed, 28 Mar 2007 11:41:16 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2SFfFgA019914; Wed, 28 Mar 2007 11:41:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2SFfDMe004129; Wed, 28 Mar 2007 11:41:13 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id vixO4kbP+bLM; Wed, 28 Mar 2007 11:41:13 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2SFf8Ch004096;Wed, 28 Mar 2007 11:41:08 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id A8EBC4FE21; Wed, 28 Mar 2007 11:37:16 -0400 (EDT) Date: Wed, 28 Mar 2007 11:37:16 -0400 From: Wesley Eddy To: Ian Chakeres Cc: "Charles E. Perkins" , manet , manet-dt@ietf.org, dtn-interest@mailman.dtnrg.org Message-ID: <20070328153716.GE5888@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <4607DBF4.8060608@nokia.com> <963155AB-4ECA-4082-96CE-1A003636C9E3@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963155AB-4ECA-4082-96CE-1A003636C9E3@gmail.com> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [dtn-interest] Re: [manet] Re: PacketBB Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, Mar 28, 2007 at 03:31:31PM +0530, Ian Chakeres wrote: > Charlie, I encouraged you (and others) to review PacketBB and to > suggest improvements. If you feel PacketBB is too heavyweight please > make specific suggestions to the authors and this list. > > I personally disagree about the expensive cost of PacketBB and the > cost of using a TLV structure. Can you please provide some specific > examples where the cost is large? Or where we might save lots of bits/ > bytes for NHDP, DYMO, or OLSRv2? In my analysis PacketBB almost > always results in fewer bits/bytes than a non-compacting format. > The IRTF Delay/Disruption-Tolerant Networking RG (DTNRG) shares some of the same concerns with MANET about saving power by transmitting fewer bits. I believe one of the techniques DTNRG is using may help the MANET packetbb a bit in this case. One concrete way to shave a few bytes is for the 'L' in each TLV, instead of using a 16-bit field, to use an SDNV (as done in the DTNRG protocols): http://www.ietf.org/internet-drafts/draft-eddy-dtn-sdnv-02.txt (an update to this draft including C code is in the works) I haven't looked closely, but I speculate that several of those Ls in the protocols that use packetbb can fit within 7 bits, and so you should save a few bytes per message by doing this, at the expense of only slightly more processing. -- Wesley M. Eddy Verizon Federal Network Systems Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2SCnAY14277 for ; Wed, 28 Mar 2007 04:49:10 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 0919B6808F for ; Wed, 28 Mar 2007 13:49:04 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A036AC05C2E; Wed, 28 Mar 2007 13:49:04 +0100 Received: from [134.226.62.161] (cswireless62-161.cs.tcd.ie [134.226.62.161]) by imx2.tcd.ie (Postfix) with ESMTP id E63E06808F for ; Wed, 28 Mar 2007 13:49:03 +0100 (IST) Message-ID: <460A6497.4040602@cs.tcd.ie> Date: Wed, 28 Mar 2007 13:50:31 +0100 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: DTN Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A136AC05C2E X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.68.7) Subject: [dtn-interest] Dublin meeting logistics/agenda Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: I've put those at [1] and linked from the wiki [2]. Let me know what's wrong/missing... Cheers, Stephen. [1] http://down.dsg.cs.tcd.ie/misc/DubAgenda.html [2] http://www.dtnrg.org/ Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2QF62Y25787 for ; Mon, 26 Mar 2007 07:06:02 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2QF60kW008889; Mon, 26 Mar 2007 10:06:00 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2QF5xMV031886; Mon, 26 Mar 2007 10:06:00 -0500 Received: from [157.185.80.152] ([157.185.80.152]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 11:05:58 -0400 From: "Peter Lovell" To: Kscott , Subject: Re: [dtn-interest] Update to bundle protocol spec. Date: Mon, 26 Mar 2007 11:05:55 -0400 Message-Id: <20070326150555.1786563621@nemo.columbia.sparta.com> In-Reply-To: References: X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-OriginalArrivalTime: 26 Mar 2007 15:05:58.0703 (UTC) FILETIME=[42B2D3F0:01C76FB8] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 26 Mar 2007 10:06:01 -0500 (CDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id l2QF62Y25787 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, Mar 14, 2007, Scott, Keith L. wrote: > >Attached is version 9 of the bundle protocol specification with the >changes to section 3.3 (Bundle Processing Control Flags) and 3.4 (Block >Processing Control Flags).  These are updates we discussed a while >back.  I'd like to submit this ASAP after the draft submission process >opens again on the 19th, so please have a look and let me know if you >see any problems. > >thanks, > > > >  --keith Hi Keith, while working on other things this weekend, I came across a problem with these changes. You have, at the reviewer's request, renumbered the fields so that they're left-to-right. That's fine for a byte-by-byte field (which is typically in network byte order) which extends to the "right". It doesn't work at all, though, for SDNVs which extend to the "left". For example, section 3.4 describes seven bits numbered 0 to 6 (MSB to LSB). What do we do when the field expands to a two-byte SDNV? The original LSB will remain LSB and the extra bits will be higher-order than the old MSB, so the field extends to the left. How will we number them?? This variable-length-field scenario might be one where we retain the other numbering scheme even though it's not the RFC standard way. Regards.....Peter Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.180]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2PJCnY16594 for ; Sun, 25 Mar 2007 11:12:50 -0800 Received: by ik-out-1112.google.com with SMTP id c21so1657405ika for ; Sun, 25 Mar 2007 12:12:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; b=fj4UKfC0ZzGojzoaoKp9IueM/gTDoCErjtrMGF933jeH2j5KsZD2uwZd2VPp51vCVB9LyKvtIJqtxlDbO9SCVbPIv9p/WYH3oIjR2otYrh/Oihfr6ToN/hQjxfifTCd6VwgMl3cYz6LBjqwrnwcK7bqJg1T2hQjYB6CLbdokEBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=j/sXlPUWwHUSilnWrpk9nECKmBVmF+kN8IFoBIFHavLTXx1EnD0D+XmxCpBXvHOmqvJCygw3XeuY2xPgVzisLoxnKpOmwhu37SDbif/LiabbyZY3cVwXPyrRfWSobyBzYuP+7cunk5+orsgiay8V54iYD/rKIROQ16UfwrTrhAo= Received: by 10.114.72.1 with SMTP id u1mr2306288waa.1174849967467; Sun, 25 Mar 2007 12:12:47 -0700 (PDT) Received: by 10.114.145.5 with HTTP; Sun, 25 Mar 2007 12:12:47 -0700 (PDT) Message-ID: Date: Sun, 25 Mar 2007 15:12:47 -0400 From: "ryan m" To: DTNRG Cc: jbush@mitre.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_239666_31915697.1174849967289" Subject: [dtn-interest] external Java router Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: ------=_Part_239666_31915697.1174849967289 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm trying to get Jeff Bush's sample external router running so that I can take a close look at the xml it has to extange to work. And get a better idea of what would be involved in writing my own router. I'm having an issue in which the sample router is starting up just fine and getting data from dtnd, but doesn't seem to be seeding anything back. I'm just using dtnping from the computer running the sample router to another computer just using static routing. I'm using a fairly recent version of dtn2 cvs, couple weeks old. The only possible cause I can see is in the counsole that I run the sample router from, I'm getting the following error message. fStart Element: Name = dtn Start Element: Name = bundle_received_event Start Element: Name = bundle Start Element: Name = source End Element: Name = source Start Element: Name = dest End Element: Name = dest Start Element: Name = custodian End Element: Name = custodian Start Element: Name = replyto End Element: Name = replyto Start Element: Name = prevhop End Element: Name = prevhop Error: org.xml.sax.SAXParseException: cvc-complex-type.4: Attribute 'filename' must appear on element 'payload'. Parser had an error:org.xml.sax.SAXException: cvc-complex-type.4: Attribute 'filename' must appear on element 'payload'. Received data from: /127.0.0.1:8001 with length: 814 any ideas on this? ------=_Part_239666_31915697.1174849967289 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'm trying to get Jeff Bush's sample external router running so tha= t I can take a close look at the xml it has to extange to work.  And g= et a better idea of what would be involved in writing my own router.  = I'm having an issue in which the sample router is starting up just fine= and getting data from dtnd, but doesn't seem to be seeding anything ba= ck.  I'm just using dtnping from the computer running the sample r= outer to another computer just using static routing.  I'm using a = fairly recent version of dtn2 cvs, couple weeks old.  The only possibl= e cause I can see is in the counsole that I run the sample router from, I&#= 39;m getting the following error message.

fStart Element:  Name =3D dtn
Start Element:  Name =3D= bundle_received_event
Start Element:  Name =3D bundle
Start Ele= ment:  Name =3D source
End Element:  Name =3D source
Start = Element:  Name =3D dest
End Element:  Name =3D dest
Start Element:  Name =3D custodian
End Element:  Name =3D = custodian
Start Element:  Name =3D replyto
End Element:  Na= me =3D replyto
Start Element:  Name =3D prevhop
End Element:&nbs= p; Name =3D prevhop
Error: org.xml.sax.SAXParseException : cvc-complex-type.4: Attribute 'filename' must appear on element &= #39;payload'.
Parser had an error:org.xml.sax.SAXException: cvc-comp= lex-type.4: Attribute 'filename' must appear on element 'payloa= d'.
Received data from: /127.0.0.1:8001 with length: 814
<dtn eid=3D&= quot;dtn://basin.cse.lehigh.edu.dtn"><bundle_expired_event>&l= t;bundle bundleid=3D"2" is_fragment=3D"false" is_admin= =3D"false" do_not_fragment=3D"false" priority=3D"0= " custody_requested=3D"false" local_custody=3D"false&qu= ot; singleton_dest=3D"true" custody_rcpt=3D"false" rece= ive_rcpt=3D"false" forward_rcpt=3D"false" delivery_rcpt= =3D"false" deletion_rcpt=3D"true" app_acked_rcpt=3D&quo= t;false" creation_ts_seconds=3D"228164413" creation_ts_seqno= =3D"2" expiration=3D"30" orig_length=3D"0" fr= ag_offset=3D"0" owner=3D""><source uri=3D"dt= n://basin.cse.lehigh.edu.dtn/ping.28793"/><dest uri=3D"dtn:= //rcm2.cse.lehigh.edu.dtn/ping"/><custodian uri=3D"dtn:none= "/><replyto uri=3D"dtn://basin.cse.lehigh.edu.dtn/ping.2879= 3"/><prevhop uri=3D""/><payload length=3D"2= 0" rcvd_length=3D"20" base_offset=3D"0"/><re= cv_blocks size=3D"0"/><api_blocks size=3D"0"/>= </bundle></bundle_expired_event></dtn>

any ideas on this?
------=_Part_239666_31915697.1174849967289-- Received: from mta16.adelphia.net (mta16.adelphia.net [68.168.78.211]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2P0DgY28969 for ; Sat, 24 Mar 2007 16:13:42 -0800 Received: from [127.0.0.1] (really [76.173.246.97]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20070325001335.DVOP25724.mta16.adelphia.net@[127.0.0.1]> for ; Sat, 24 Mar 2007 20:13:35 -0400 Message-ID: <4605BEAF.9010508@jpl.nasa.gov> Date: Sat, 24 Mar 2007 17:13:35 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] "EID reference" proposal References: <20070323163037.1353155004@127.0.0.1> <46054644.7050300@cs.tcd.ie> <4605781C.1030003@jpl.nasa.gov> <460593E4.4050900@cs.tcd.ie> In-Reply-To: <460593E4.4050900@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Stephen Farrell wrote: > Scott Burleigh wrote: >> Stephen Farrell wrote: >>> >>> Hi Pete, >>> >>> I have two problems with this: >>> >>> 1) The BP is supposed to be done, but this is a substantive >>> change to the protocol. I think its too late for now to make >>> such changes unless we want to reset the BP review process >>> (which is a slow and moving target). So - is this important >>> enough to do that? >> >> I was uneasy about this too, Stephen, and if we have already initiated >> the high-powered IETF review of BP then I guess I would want to think >> twice before making this change. But if we're not talking about a >> total reset then for once I think these last-minute changes really are >> important enough to squeeze in. > > Not sure about "high-powered", but we're at the last substantive > review already, so if we make a change, then we should reset that. > The problem really is that that review process is a moving target, > so the reset can result in a lot of delay. Well, that does make me less enthusiastic. Maybe carrying the EIDs inside the BSP blocks is a design infelicity that we're just going to have to live with until the next version. Not good for a space deployment, but the space infusion activities take so long that we might already be on the next iteration of BP version standardization by the time it matters. >> I think the bundle protocol's security model is going to turn out to >> be one of the most compelling reasons to adopt DTN. My understanding >> is that BSP can be made to work without any change to BP, but only if >> all endpoint IDs used by BSP are carried within the security blocks >> themselves rather than in the dictionary. This could result in >> heavier block overhead than some users would feel comfortable with, >> and in particular I think it would make BSP a non-starter for space >> flight applications; I would need to develop some sort of >> CBHE-amenable counterpart protocol that would almost certainly be >> non-interoperable with BSP, and I really want not to do that. So I >> think making this change is a good long-term investment. > > I agree that the security model is important. However, we have > to stop changing it sometime. (I've also some more DTN security > stuff to suggest, having chatted with Joerg in Prague, see a > separate mail in a bit.) > >>> 2) The proposal seems to be splitting dictionary info across >>> the various blocks. If we're changing the protocol, then >>> perhaps there are other ways that ought be considered (e.g. >>> including a block count or something in the dictionary), so >>> I'd not be too keen on just ok-ing this without considering >>> other options on the list. >> >> The dictionary itself would still be only in one place, at the end of >> the primary block. All that would really change is that any extension >> block that wanted to use EID references into the dictionary (as the >> primary block does) could only do so by collecting all those >> references into an array at a standard location within the preamble of >> the extension block. >> >> This would make it unnecessary for a bundle agent to delete an >> extension block (such as a security block) that it doesn't know how to >> process, just because it wants to compress the dictionary: since all >> the references to strings in the dictionary would be knowable even >> when some extension blocks can't be processed, the agent would be able >> to know which strings really are no longer referenced and also to >> adjust references (offsets) as necessary if any referenced strings >> move within the dictionary as a result of compression. >> >> And, handily enough, it also would enable straightforward CBHE >> compression of all extension blocks, which could solve a lot of >> problems for me. > > That's all fine. However, there is presumably an equivalent solution > where we put all the pointers in the dictionary rather than in the > blocks. I'm not saying I prefer that, just that if we do want to make > such a change we should consider more than just one solution. > > We should only do this, if its worthwhile. If its worthwhile we should > do it well, once, and in a considered manner. I certainly agree that it should be done in a considered manner if we do it at all. Can you say something about the equivalent solution you have in mind? Currently there are no pointers at all in the dictionary, only the strings that the EID references point to. Are you proposing that all EID references themselves be inserted into the primary block (where the dictionary lives)? With, I guess, forward pointers to the fields (possibly in other blocks) that they pertain to, so that a bundle agent looking at a given block can pick out the relevant EID strings? Or are you thinking of having a table of EID references in the primary block and carrying only subscripts into that table as twice-indirect endpoint ID references in the other blocks? Worth talking about, but these kinds of variations seem to me to be more complex and less bit-efficient than the one Peter is proposing. Scott Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2OLMBY27965 for ; Sat, 24 Mar 2007 13:22:11 -0800 Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 2A3583210F for ; Sat, 24 Mar 2007 21:22:10 +0000 (GMT) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l2OLM85x027386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 24 Mar 2007 21:22:09 GMT Message-ID: <460596D2.8060100@cs.tcd.ie> Date: Sat, 24 Mar 2007 21:23:30 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: DTN Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 6865081 - 740eb8431183 X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Subject: [dtn-interest] DTN security work in Dublin and beyond... Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi all, Had a couple of interesting chats with Joerg in Prague about what we might want to get started on at the Dublin meeting and where that might go. The subjects I think we want to tackle there are: 1. progressing the current security specs 2. getting started on key management 3. thinking about adding capabilities (In fact, I think I'd discuss 'em in reverse order.) #1 is fairly clear and not necessarily that much work (if #2 and #3 don't affect the blocks). For #2 I think best for now is to write down some requirements (e.g. "DTN key mgmt interchanges MUST be able to occur via different contacts") and I'll try get that started before the Dublin meeting. Let me know if you'd like to help. I think that some requirements might help to structure discussion in Dublin about IBE vs. key transport etc. The issue with #3 is down to passing around information that can be used to authorize various aspects of bundle processing. For example, I think a capability that says that some authority has authorized this router to take custody of bundles from this source might be useful. (In fact, such a capability might even be an extension of the PSB.) I'd expect that this would only be ppt for May 21, but might get a chance to do something more substantive. To be clear, I think #2 and #3, if we tackle them, will result in two new documents. Stephen. PS: Joerg - did I forget anything there? Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2OL9gY27837 for ; Sat, 24 Mar 2007 13:09:42 -0800 Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 9D72B320EF; Sat, 24 Mar 2007 21:09:41 +0000 (GMT) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l2OL9cBe026845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Mar 2007 21:09:39 GMT Message-ID: <460593E4.4050900@cs.tcd.ie> Date: Sat, 24 Mar 2007 21:11:00 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Scott Burleigh CC: dtn interest Subject: Re: [dtn-interest] "EID reference" proposal References: <20070323163037.1353155004@127.0.0.1> <46054644.7050300@cs.tcd.ie> <4605781C.1030003@jpl.nasa.gov> In-Reply-To: <4605781C.1030003@jpl.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 6864419 - f143924ae54d (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Scott Burleigh wrote: > Stephen Farrell wrote: >> >> Hi Pete, >> >> I have two problems with this: >> >> 1) The BP is supposed to be done, but this is a substantive >> change to the protocol. I think its too late for now to make >> such changes unless we want to reset the BP review process >> (which is a slow and moving target). So - is this important >> enough to do that? > > I was uneasy about this too, Stephen, and if we have already initiated > the high-powered IETF review of BP then I guess I would want to think > twice before making this change. But if we're not talking about a total > reset then for once I think these last-minute changes really are > important enough to squeeze in. Not sure about "high-powered", but we're at the last substantive review already, so if we make a change, then we should reset that. The problem really is that that review process is a moving target, so the reset can result in a lot of delay. > I think the bundle protocol's security model is going to turn out to be > one of the most compelling reasons to adopt DTN. My understanding is > that BSP can be made to work without any change to BP, but only if all > endpoint IDs used by BSP are carried within the security blocks > themselves rather than in the dictionary. This could result in heavier > block overhead than some users would feel comfortable with, and in > particular I think it would make BSP a non-starter for space flight > applications; I would need to develop some sort of CBHE-amenable > counterpart protocol that would almost certainly be non-interoperable > with BSP, and I really want not to do that. So I think making this > change is a good long-term investment. I agree that the security model is important. However, we have to stop changing it sometime. (I've also some more DTN security stuff to suggest, having chatted with Joerg in Prague, see a separate mail in a bit.) >> 2) The proposal seems to be splitting dictionary info across >> the various blocks. If we're changing the protocol, then >> perhaps there are other ways that ought be considered (e.g. >> including a block count or something in the dictionary), so >> I'd not be too keen on just ok-ing this without considering >> other options on the list. > > The dictionary itself would still be only in one place, at the end of > the primary block. All that would really change is that any extension > block that wanted to use EID references into the dictionary (as the > primary block does) could only do so by collecting all those references > into an array at a standard location within the preamble of the > extension block. > > This would make it unnecessary for a bundle agent to delete an extension > block (such as a security block) that it doesn't know how to process, > just because it wants to compress the dictionary: since all the > references to strings in the dictionary would be knowable even when some > extension blocks can't be processed, the agent would be able to know > which strings really are no longer referenced and also to adjust > references (offsets) as necessary if any referenced strings move within > the dictionary as a result of compression. > > And, handily enough, it also would enable straightforward CBHE > compression of all extension blocks, which could solve a lot of problems > for me. That's all fine. However, there is presumably an equivalent solution where we put all the pointers in the dictionary rather than in the blocks. I'm not saying I prefer that, just that if we do want to make such a change we should consider more than just one solution. We should only do this, if its worthwhile. If its worthwhile we should do it well, once, and in a considered manner. S. Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2OKxGY27767 for ; Sat, 24 Mar 2007 12:59:16 -0800 Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id DF22D3212A; Sat, 24 Mar 2007 20:59:14 +0000 (GMT) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l2OKxCfI026404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Mar 2007 20:59:12 GMT Message-ID: <46059172.6050405@cs.tcd.ie> Date: Sat, 24 Mar 2007 21:00:34 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Peter Lovell CC: dtn interest Subject: Re: [dtn-interest] "EID reference" proposal References: <20070323163037.1353155004@127.0.0.1> <46054644.7050300@cs.tcd.ie> <20070324185820.683907936@127.0.0.1> In-Reply-To: <20070324185820.683907936@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 6864179 - 6053534f2dd8 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Peter Lovell wrote: > Hi Stephen, > > On Sat, Mar 24, 2007, Stephen Farrell wrote: > >> I have two problems with this: >> >> 1) The BP is supposed to be done, but this is a substantive >> change to the protocol. I think its too late for now to make >> such changes unless we want to reset the BP review process >> (which is a slow and moving target). So - is this important >> enough to do that? > > This was also a concern of mine [also see 3rd para]. Keith circulated an > updated BP draft recently last week so I think the process is perhaps > not as far along as we had thought. I've not seen an update since then. That update basically reflected the changes due to the first IRSG review (our 2nd one is still missing). If we make this change now, then we should probably get two more reviews. Its taken months to get one and get the resulting changes into an I-D. So, making this change is not a case of just adding stuff now. (The rules for IRSG reviews aren't that well defined however, so we might get a substantive change without a re-start to the process; however, I suspect that that'd be frowned upon.) My guess is that substantively changing this now could possibly (pessimistically) add 4-6 months to the time for the BP to become an RFC. > The substantive part of the change is really in the extension block > specifications, such as the security specification (even there is is > small). The change to BP itself is minor since neither of the blocks > closely defined there are affected. To be sure, there are code > implications but those are implementation issues rather than ones for > the protocol. So I disagree with you a bit -- the change is non-trivial > for the entire protocol, including extensions, but very minor for that > part of the protocol described in BP. Wrong. Its a change to the bits on the wire and to the processing. And it to an extent invalidates our interop. That's a non-trivial change. > During discussions with Scott Burleigh and Mike Demmer, I had suggested > at one point that we put this proposal into a separate specification, > since the changes apply to extension blocks. This would eliminate the > need for the textual change to BP and collect the extension-specific > things into one place. The consensus was that it would be better to have > these all in one place together, but either way is fine. If the > community would prefer that it be separate then I'm happy to prepare a > specification for it. > > Scott says he thinks it's important enough to include in the spec before > we submit it and Mike agreed. Its ok to do that. But we just need to be aware of the cost as well as benefits. The cost is, IMO, measured in months, not weeks. >> 2) The proposal seems to be splitting dictionary info across >> the various blocks. If we're changing the protocol, then >> perhaps there are other ways that ought be considered (e.g. >> including a block count or something in the dictionary), so >> I'd not be too keen on just ok-ing this without considering >> other options on the list. > > It does seem that way but in fact this is not a change. BP already > describes the way in which extension blocks use EID references and how > these are stored in the dictionary. So the info is already split under > the current protocol. And the references can be stored anywhere. > > What this proposal does is gather the references into one standardized > place where they can be readily located as part of dictionary- > management, as opposed to allowing them to be hidden away in the > extension-block-private fields. I think this is a substantial > improvement to the robustness of the protocol. Possibly. But since any such change will add months, there's no need to rush, if we agree that the feature is worthwhile. S. Received: from Ambrosius.sparta.com (ambrosius.sparta.com [158.69.0.1]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2OJOPY26993 for ; Sat, 24 Mar 2007 11:24:25 -0800 Received: from durin.laguna.sparta.com ([157.185.1.7]) by Ambrosius.sparta.com (8.13.8/8.13.8) with ESMTP id l2OJONte032588; Sat, 24 Mar 2007 12:24:23 -0700 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by durin.laguna.sparta.com (8.13.1/8.13.1) with ESMTP id l2OJOMSg019746; Sat, 24 Mar 2007 12:24:22 -0700 (PDT) Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Mar 2007 15:24:21 -0400 From: "Peter Lovell" To: "Stephen Farrell" Cc: "dtn interest" Subject: Re(2): [dtn-interest] "EID reference" proposal Date: Sat, 24 Mar 2007 14:58:20 -0400 Message-Id: <20070324185820.683907936@127.0.0.1> In-Reply-To: <46054644.7050300@cs.tcd.ie> References: <20070323163037.1353155004@127.0.0.1> <46054644.7050300@cs.tcd.ie> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2007 19:24:21.0948 (UTC) FILETIME=[0686C7C0:01C76E4A] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (Ambrosius.sparta.com [158.69.0.1]); Sat, 24 Mar 2007 12:24:23 -0700 (PDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi Stephen, On Sat, Mar 24, 2007, Stephen Farrell wrote: >I have two problems with this: > >1) The BP is supposed to be done, but this is a substantive >change to the protocol. I think its too late for now to make >such changes unless we want to reset the BP review process >(which is a slow and moving target). So - is this important >enough to do that? This was also a concern of mine [also see 3rd para]. Keith circulated an updated BP draft recently last week so I think the process is perhaps not as far along as we had thought. I've not seen an update since then. The substantive part of the change is really in the extension block specifications, such as the security specification (even there is is small). The change to BP itself is minor since neither of the blocks closely defined there are affected. To be sure, there are code implications but those are implementation issues rather than ones for the protocol. So I disagree with you a bit -- the change is non-trivial for the entire protocol, including extensions, but very minor for that part of the protocol described in BP. During discussions with Scott Burleigh and Mike Demmer, I had suggested at one point that we put this proposal into a separate specification, since the changes apply to extension blocks. This would eliminate the need for the textual change to BP and collect the extension-specific things into one place. The consensus was that it would be better to have these all in one place together, but either way is fine. If the community would prefer that it be separate then I'm happy to prepare a specification for it. Scott says he thinks it's important enough to include in the spec before we submit it and Mike agreed. > >2) The proposal seems to be splitting dictionary info across >the various blocks. If we're changing the protocol, then >perhaps there are other ways that ought be considered (e.g. >including a block count or something in the dictionary), so >I'd not be too keen on just ok-ing this without considering >other options on the list. It does seem that way but in fact this is not a change. BP already describes the way in which extension blocks use EID references and how these are stored in the dictionary. So the info is already split under the current protocol. And the references can be stored anywhere. What this proposal does is gather the references into one standardized place where they can be readily located as part of dictionary- management, as opposed to allowing them to be hidden away in the extension-block-private fields. I think this is a substantial improvement to the robustness of the protocol. Cheers.....Peter Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2OJCYY26906 for ; Sat, 24 Mar 2007 11:12:34 -0800 Received: from [127.0.0.1] (really [76.173.246.97]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20070324191228.FAVE2196.mta9.adelphia.net@[127.0.0.1]> for ; Sat, 24 Mar 2007 15:12:28 -0400 Message-ID: <4605781C.1030003@jpl.nasa.gov> Date: Sat, 24 Mar 2007 12:12:28 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] "EID reference" proposal References: <20070323163037.1353155004@127.0.0.1> <46054644.7050300@cs.tcd.ie> In-Reply-To: <46054644.7050300@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Stephen Farrell wrote: > > Hi Pete, > > I have two problems with this: > > 1) The BP is supposed to be done, but this is a substantive > change to the protocol. I think its too late for now to make > such changes unless we want to reset the BP review process > (which is a slow and moving target). So - is this important > enough to do that? I was uneasy about this too, Stephen, and if we have already initiated the high-powered IETF review of BP then I guess I would want to think twice before making this change. But if we're not talking about a total reset then for once I think these last-minute changes really are important enough to squeeze in. I think the bundle protocol's security model is going to turn out to be one of the most compelling reasons to adopt DTN. My understanding is that BSP can be made to work without any change to BP, but only if all endpoint IDs used by BSP are carried within the security blocks themselves rather than in the dictionary. This could result in heavier block overhead than some users would feel comfortable with, and in particular I think it would make BSP a non-starter for space flight applications; I would need to develop some sort of CBHE-amenable counterpart protocol that would almost certainly be non-interoperable with BSP, and I really want not to do that. So I think making this change is a good long-term investment. > 2) The proposal seems to be splitting dictionary info across > the various blocks. If we're changing the protocol, then > perhaps there are other ways that ought be considered (e.g. > including a block count or something in the dictionary), so > I'd not be too keen on just ok-ing this without considering > other options on the list. The dictionary itself would still be only in one place, at the end of the primary block. All that would really change is that any extension block that wanted to use EID references into the dictionary (as the primary block does) could only do so by collecting all those references into an array at a standard location within the preamble of the extension block. This would make it unnecessary for a bundle agent to delete an extension block (such as a security block) that it doesn't know how to process, just because it wants to compress the dictionary: since all the references to strings in the dictionary would be knowable even when some extension blocks can't be processed, the agent would be able to know which strings really are no longer referenced and also to adjust references (offsets) as necessary if any referenced strings move within the dictionary as a result of compression. And, handily enough, it also would enable straightforward CBHE compression of all extension blocks, which could solve a lot of problems for me. Scott > Peter Lovell wrote: >> I've been working recently on updates to the bundle security protocol >> specification, and sorting out several issues. This is moving along well >> and I plan to circulate an updated draft during next week. >> >> First, a little background. One of the issues relates to allowing the >> security protocol to make use of the dictionary in the primary block for >> storage of EIDs. Extension block code may make use of the dictionary >> but, and here's the rub, only if the block is allowed to be discarded at >> any intermediate node. Not surprisingly, this doesn't fit well with the >> notion of "security". In discussion with Mike Demmer and others, it >> turns out that the reason behind this is that a bundle node might >> compress the dictionary and, if some blocks can't be processed at that >> node, it wouldn't know what dictionary entries were still needed and >> which should be discarded. The current approach is to delete the block >> (or bundle) if it can't be processed. Some might wonder why we want to >> use the dictionary - it's because EID strings can be quite large and the >> same string often occurs in several places. Using the dictionary allows >> it to appear only once. There are some additional details but those are >> more than we need for the present discussion. >> >> So the real issue is how to validate references to the dictionary in a >> way which is ... >> 1. useful for extension block code >> 2. not specific to any one extension or group >> 3. allows collection in the dictionary (deletion of entries which are no >> longer used) >> 4. minimal impact to existing specifications and code >> >> Several possible solutions were discussed and the one which best meets >> these criteria is the one fron Jon Olson. I'm proposing this for >> inclusion in the current draft of the specification for bundle protocol >> [BP] and simultaneously for the bundle security protocol [BSP], also >> under revision right now. Fortunately the changes for bundle protocol >> are very minor, unfortunately (for me :) the ones for the security >> protocol are a big bigger. >> >> The definition of the primary block and security block - the main focus >> of BP - remain unchanged. Extensions which store EIDs in the dictionary, >> which is optional, make use of a new field in the preamble at the start >> of the block. The preamble is the group of standard fields at the >> beginning of all blocks expect the primary block. It is defined in BP >> section 3.2 and consists of block type, flags and length. If an >> extension wishes to store EIDs in the dictionary, it must store the EID >> references in a new composite field following the "length" field. This >> composite field is a count (SDNV) indicating the number of EID >> references, followed by the references themselves. If this composite >> field exists, the fact is indicated by setting a header flag, >> described below. >> >> Since we (propose to) define this as part of the preamble, it is >> "present" in every block (except primary). All extensions may use it and >> the bundle daemon can always find it. If it's not actually used then it >> takes no space, as we do not store a zero count if the field is not used. >> >> The flag is the one described as "bit 0" in BP section 3.4, and is >> currently allocated for use by the security protocol. If set, the EID >> reference field (that is, the composite field, comprising the count and >> the references) is present, if un-set then the block has no EID >> references in the dictionary. Note that if it is un-set then the block >> format is exactly the same as current definitions - no change at all is >> needed unless the authors of extension code choose to use this >> capability. >> >> If we implement this proposal then we can delete the restrictions in BP >> section 3.7 paragraphs 2 and 3. These are the ones which require a >> "delete/discard" flag to be set if an extension makes use of the >> dictionary. While this might seem like a minor benefit, it will have a >> substantial impact on security processing and possibly many other >> extension-block users. >> >> >> Thanks.....Peter >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@mailman.dtnrg.org >> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest >> > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2OFcWY25669 for ; Sat, 24 Mar 2007 07:38:32 -0800 Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id E5B03320E3; Sat, 24 Mar 2007 15:38:30 +0000 (GMT) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l2OFcQXa000638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Mar 2007 15:38:26 GMT Message-ID: <46054644.7050300@cs.tcd.ie> Date: Sat, 24 Mar 2007 15:39:48 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Peter Lovell CC: dtn interest Subject: Re: [dtn-interest] "EID reference" proposal References: <20070323163037.1353155004@127.0.0.1> In-Reply-To: <20070323163037.1353155004@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 6850189 - d9738a242a9f (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi Pete, I have two problems with this: 1) The BP is supposed to be done, but this is a substantive change to the protocol. I think its too late for now to make such changes unless we want to reset the BP review process (which is a slow and moving target). So - is this important enough to do that? 2) The proposal seems to be splitting dictionary info across the various blocks. If we're changing the protocol, then perhaps there are other ways that ought be considered (e.g. including a block count or something in the dictionary), so I'd not be too keen on just ok-ing this without considering other options on the list. S. Peter Lovell wrote: > I've been working recently on updates to the bundle security protocol > specification, and sorting out several issues. This is moving along well > and I plan to circulate an updated draft during next week. > > First, a little background. One of the issues relates to allowing the > security protocol to make use of the dictionary in the primary block for > storage of EIDs. Extension block code may make use of the dictionary > but, and here's the rub, only if the block is allowed to be discarded at > any intermediate node. Not surprisingly, this doesn't fit well with the > notion of "security". In discussion with Mike Demmer and others, it > turns out that the reason behind this is that a bundle node might > compress the dictionary and, if some blocks can't be processed at that > node, it wouldn't know what dictionary entries were still needed and > which should be discarded. The current approach is to delete the block > (or bundle) if it can't be processed. Some might wonder why we want to > use the dictionary - it's because EID strings can be quite large and the > same string often occurs in several places. Using the dictionary allows > it to appear only once. There are some additional details but those are > more than we need for the present discussion. > > So the real issue is how to validate references to the dictionary in a > way which is ... > 1. useful for extension block code > 2. not specific to any one extension or group > 3. allows collection in the dictionary (deletion of entries which are no > longer used) > 4. minimal impact to existing specifications and code > > Several possible solutions were discussed and the one which best meets > these criteria is the one fron Jon Olson. I'm proposing this for > inclusion in the current draft of the specification for bundle protocol > [BP] and simultaneously for the bundle security protocol [BSP], also > under revision right now. Fortunately the changes for bundle protocol > are very minor, unfortunately (for me :) the ones for the security > protocol are a big bigger. > > The definition of the primary block and security block - the main focus > of BP - remain unchanged. Extensions which store EIDs in the dictionary, > which is optional, make use of a new field in the preamble at the start > of the block. The preamble is the group of standard fields at the > beginning of all blocks expect the primary block. It is defined in BP > section 3.2 and consists of block type, flags and length. If an > extension wishes to store EIDs in the dictionary, it must store the EID > references in a new composite field following the "length" field. This > composite field is a count (SDNV) indicating the number of EID > references, followed by the references themselves. If this composite > field exists, the fact is indicated by setting a header flag, described below. > > Since we (propose to) define this as part of the preamble, it is > "present" in every block (except primary). All extensions may use it and > the bundle daemon can always find it. If it's not actually used then it > takes no space, as we do not store a zero count if the field is not used. > > The flag is the one described as "bit 0" in BP section 3.4, and is > currently allocated for use by the security protocol. If set, the EID > reference field (that is, the composite field, comprising the count and > the references) is present, if un-set then the block has no EID > references in the dictionary. Note that if it is un-set then the block > format is exactly the same as current definitions - no change at all is > needed unless the authors of extension code choose to use this capability. > > If we implement this proposal then we can delete the restrictions in BP > section 3.7 paragraphs 2 and 3. These are the ones which require a > "delete/discard" flag to be set if an extension makes use of the > dictionary. While this might seem like a minor benefit, it will have a > substantial impact on security processing and possibly many other > extension-block users. > > > Thanks.....Peter > > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > Received: from Ambrosius.sparta.com (ambrosius.sparta.com [158.69.0.1]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2NGUdY15820 for ; Fri, 23 Mar 2007 08:30:39 -0800 Received: from durin.laguna.sparta.com ([157.185.1.7]) by Ambrosius.sparta.com (8.13.8/8.13.8) with ESMTP id l2NGUcLY032477 for ; Fri, 23 Mar 2007 09:30:38 -0700 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by durin.laguna.sparta.com (8.13.1/8.13.1) with ESMTP id l2NGUc6G020295 for ; Fri, 23 Mar 2007 09:30:38 -0700 (PDT) Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 12:30:37 -0400 From: "Peter Lovell" To: "dtn interest" Date: Fri, 23 Mar 2007 12:30:37 -0400 Message-Id: <20070323163037.1353155004@127.0.0.1> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2007 16:30:38.0040 (UTC) FILETIME=[96FAE580:01C76D68] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (Ambrosius.sparta.com [158.69.0.1]); Fri, 23 Mar 2007 09:30:38 -0700 (PDT) Subject: [dtn-interest] "EID reference" proposal Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: I've been working recently on updates to the bundle security protocol specification, and sorting out several issues. This is moving along well and I plan to circulate an updated draft during next week. First, a little background. One of the issues relates to allowing the security protocol to make use of the dictionary in the primary block for storage of EIDs. Extension block code may make use of the dictionary but, and here's the rub, only if the block is allowed to be discarded at any intermediate node. Not surprisingly, this doesn't fit well with the notion of "security". In discussion with Mike Demmer and others, it turns out that the reason behind this is that a bundle node might compress the dictionary and, if some blocks can't be processed at that node, it wouldn't know what dictionary entries were still needed and which should be discarded. The current approach is to delete the block (or bundle) if it can't be processed. Some might wonder why we want to use the dictionary - it's because EID strings can be quite large and the same string often occurs in several places. Using the dictionary allows it to appear only once. There are some additional details but those are more than we need for the present discussion. So the real issue is how to validate references to the dictionary in a way which is ... 1. useful for extension block code 2. not specific to any one extension or group 3. allows collection in the dictionary (deletion of entries which are no longer used) 4. minimal impact to existing specifications and code Several possible solutions were discussed and the one which best meets these criteria is the one fron Jon Olson. I'm proposing this for inclusion in the current draft of the specification for bundle protocol [BP] and simultaneously for the bundle security protocol [BSP], also under revision right now. Fortunately the changes for bundle protocol are very minor, unfortunately (for me :) the ones for the security protocol are a big bigger. The definition of the primary block and security block - the main focus of BP - remain unchanged. Extensions which store EIDs in the dictionary, which is optional, make use of a new field in the preamble at the start of the block. The preamble is the group of standard fields at the beginning of all blocks expect the primary block. It is defined in BP section 3.2 and consists of block type, flags and length. If an extension wishes to store EIDs in the dictionary, it must store the EID references in a new composite field following the "length" field. This composite field is a count (SDNV) indicating the number of EID references, followed by the references themselves. If this composite field exists, the fact is indicated by setting a header flag, described below. Since we (propose to) define this as part of the preamble, it is "present" in every block (except primary). All extensions may use it and the bundle daemon can always find it. If it's not actually used then it takes no space, as we do not store a zero count if the field is not used. The flag is the one described as "bit 0" in BP section 3.4, and is currently allocated for use by the security protocol. If set, the EID reference field (that is, the composite field, comprising the count and the references) is present, if un-set then the block has no EID references in the dictionary. Note that if it is un-set then the block format is exactly the same as current definitions - no change at all is needed unless the authors of extension code choose to use this capability. If we implement this proposal then we can delete the restrictions in BP section 3.7 paragraphs 2 and 3. These are the ones which require a "delete/discard" flag to be set if an extension makes use of the dictionary. While this might seem like a minor benefit, it will have a substantial impact on security processing and possibly many other extension-block users. Thanks.....Peter Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2NF7mY15325 for ; Fri, 23 Mar 2007 07:07:48 -0800 Received: from sneetch.bbn.com ([128.89.80.78]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HUlMk-0008ED-5p; Fri, 23 Mar 2007 11:07:42 -0400 Message-ID: <4603ED3E.7000906@bbn.com> Date: Fri, 23 Mar 2007 11:07:42 -0400 From: Christopher Small User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dtn-interest] DTN BoF session at NSD'07 in Cambridge April 11 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: There will be a DTN birds-of-a-feather session at NSDI'07 (Networked Systems Design and Implementation) being held in Cambridge MA from April 11-13. See http://www.usenix.org/events/nsdi07 for details on the conference. The BoF will be from 8:00PM-9:00PM on Wednesday April 11, just after the poster session / reception. (Right now the on-line schedule shows it as being on April 12, but that should be fixed soon.) My goal for the BoF is for people to give short talks on what they are doing (sort of like what was done at the last IETF) and share ideas for future DTN research. (Also, no promises, but I'm trying to get my management to provide beer and pretzels.) I'll manage a sign-up sheet for time slots; drop me a line if you're interested in talking and for how long. USENIX will provide an LCD projector. - Chris -- Dr. Christopher Small 617.873.6261 (vox) Networking Research x(){ x|x& };x 617.873.6091 (fax) BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2MHxWY06557 for ; Thu, 22 Mar 2007 09:59:32 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2MHxUa1015937; Thu, 22 Mar 2007 12:59:30 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2MHxU1i006448; Thu, 22 Mar 2007 12:59:30 -0500 Received: from [192.168.4.101] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 13:59:29 -0400 From: "Peter Lovell" To: "Kevin Fall" Cc: "dtn interest" Subject: Re(2): [dtn-interest] will there be a call today Date: Thu, 22 Mar 2007 13:59:27 -0400 Message-Id: <20070322175927.551212462@127.0.0.1> In-Reply-To: <3B383B4B-2AF3-48B7-8EED-7BB7972C5BFA@cs.Berkeley.EDU> References: <20070322140022.754994501@127.0.0.1> <3B383B4B-2AF3-48B7-8EED-7BB7972C5BFA@cs.Berkeley.EDU> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (intel) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2007 17:59:29.0328 (UTC) FILETIME=[D6432300:01C76CAB] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Thu, 22 Mar 2007 12:59:30 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Thu, Mar 22, 2007, Kevin Fall wrote: >Stephen and I are at IETF in Prague, so at least we won't be able to... > >I'd be curious in finding out how many folks are planning to come to >Ireland for the interim meeting..? > >- K > >On Mar 22, 2007, at 7:00 AM@Mar 22, 2007, Peter Lovell wrote: > >> Are we planning a call today? >> >> Thanks.....Peter >> Hi Kevin, I'm planning to be there and will discuss security implementation. Cheers.....Peter Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2MFr1Y05779 for ; Thu, 22 Mar 2007 07:53:01 -0800 Received: from [130.129.21.116] (dhcp-1574.ietf68.org [130.129.21.116]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.0/8.13.5) with ESMTP id l2MFqwEq013467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Mar 2007 08:53:01 -0700 (PDT) In-Reply-To: <20070322140022.754994501@127.0.0.1> References: <20070322140022.754994501@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B383B4B-2AF3-48B7-8EED-7BB7972C5BFA@cs.Berkeley.EDU> Cc: dtn interest Content-Transfer-Encoding: 7bit From: Kevin Fall Subject: Re: [dtn-interest] will there be a call today Date: Thu, 22 Mar 2007 08:52:54 -0700 To: Peter Lovell X-Mailer: Apple Mail (2.752.3) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Stephen and I are at IETF in Prague, so at least we won't be able to... I'd be curious in finding out how many folks are planning to come to Ireland for the interim meeting..? - K On Mar 22, 2007, at 7:00 AM@Mar 22, 2007, Peter Lovell wrote: > Are we planning a call today? > > Thanks.....Peter > > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2ME0SY05103 for ; Thu, 22 Mar 2007 06:00:28 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2ME0RE6002450 for ; Thu, 22 Mar 2007 09:00:27 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2ME0Ql8030329 for ; Thu, 22 Mar 2007 09:00:26 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 10:00:25 -0400 From: "Peter Lovell" To: "dtn interest" Date: Thu, 22 Mar 2007 10:00:22 -0400 Message-Id: <20070322140022.754994501@127.0.0.1> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2007 14:00:26.0159 (UTC) FILETIME=[71113BF0:01C76C8A] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Thu, 22 Mar 2007 09:00:27 -0500 (CDT) Subject: [dtn-interest] will there be a call today Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Are we planning a call today? Thanks.....Peter Received: from nmta2.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.215]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2LGOiY29083 for ; Wed, 21 Mar 2007 08:24:44 -0800 Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta2.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2LGOc2I025242 for ; Wed, 21 Mar 2007 09:24:38 -0700 Received: from [127.0.0.1] (dhcp-79-22-247.jpl.nasa.gov [137.79.22.247]) by xmta3.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2LGOatn018799 for ; Wed, 21 Mar 2007 09:24:38 -0700 Message-ID: <46015C43.9010907@jpl.nasa.gov> Date: Wed, 21 Mar 2007 09:24:35 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] questions re bundle dictionary and flags References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> <46007D70.3050706@jpl.nasa.gov> <4600AC55.5090908@jpl.nasa.gov> <4600DB4B.2090808@cs.tcd.ie> <20070321134626.1384641441@nemo.columbia.sparta.com> In-Reply-To: <20070321134626.1384641441@nemo.columbia.sparta.com> Content-Type: multipart/alternative; boundary="------------080907000106030900070707" X-Source-IP: dhcp-79-22-247.jpl.nasa.gov [137.79.22.247] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. --------------080907000106030900070707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Lovell wrote: > On Wed, Mar 21, 2007, Stephen Farrell wrote: > > >> Scott Burleigh wrote: >> >>> This seems pretty unambiguous to me; I think we're still on safe ground >>> with NULL-terminated strings. >>> >> I think that's only because we restrict to URIs and not IRIs though, >> right? (I'll check with someone here at the IETF.) >> >> S. >> > > We're OK with NULL-terminated strings because section 3.5 says ... > > Each endpoint ID conveyed in any bundle block takes the form > of a Uniform Resource Identifier (URI; [RFC3986]). > > However, things then become confusing at the end of that section, which > says ... > > Note that, although the endpoint IDs conveyed in bundle blocks are > expressed as URIs, implementations of the BP service interface may > support expression of endpoint IDs in some internationalized manner > (e.g., IRIs; see RFC 3987). > > I take this to mean that IRIs, if supported, must be transformed IRI -> > URI [as described in rfc3987] before sending. > Exactly. A "service interface" implementation -- an API, a GUI -- is free to operate on IRIs, but the EIDs in bundles must be URIs. Conversion from one to the other is an implementation matter. Scott --------------080907000106030900070707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Lovell wrote: 
On Wed, Mar 21, 2007, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

  
Scott Burleigh wrote:
    
This seems pretty unambiguous to me; I think we're still on safe ground 
with NULL-terminated strings.
      
I think that's only because we restrict to URIs and not IRIs though,
right? (I'll check with someone here at the IETF.)

S.
    

We're OK with NULL-terminated strings because section 3.5 says ...

  Each endpoint ID conveyed in any bundle block takes the form
  of a Uniform Resource Identifier (URI; [RFC3986]).

However, things then become confusing at the end of that section, which
says ...    

   Note that, although the endpoint IDs conveyed in bundle blocks are 
   expressed as URIs, implementations of the BP service interface may 
   support expression of endpoint IDs in some internationalized manner 
   (e.g., IRIs; see RFC 3987). 

I take this to mean that IRIs, if supported, must be transformed IRI ->
URI [as described in rfc3987] before sending.
Exactly.  A "service interface" implementation -- an API, a GUI -- is free to operate on IRIs, but the EIDs in bundles must be URIs.  Conversion from one to the other is an implementation matter.

Scott

--------------080907000106030900070707-- Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2LFOnY28694 for ; Wed, 21 Mar 2007 07:24:49 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2LFOehw009161; Wed, 21 Mar 2007 10:24:40 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2LFOefs023574; Wed, 21 Mar 2007 10:24:40 -0500 Received: from [157.185.80.152] ([157.185.80.152]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 11:24:39 -0400 From: "Peter Lovell" To: "Stephen Farrell" Cc: "Scott Burleigh" , "dtn interest" Subject: Re(2): [dtn-interest] questions re bundle dictionary and flags Date: Wed, 21 Mar 2007 11:24:38 -0400 Message-Id: <20070321152438.883834754@nemo.columbia.sparta.com> In-Reply-To: <4601466F.80501@cs.tcd.ie> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> <46007D70.3050706@jpl.nasa.gov> <4600AC55.5090908@jpl.nasa.gov> <4600DB4B.2090808@cs.tcd.ie> <20070321134626.1384641441@nemo.columbia.sparta.com> <4601466F.80501@cs.tcd.ie> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 15:24:39.0788 (UTC) FILETIME=[0ADA12C0:01C76BCD] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Wed, 21 Mar 2007 10:24:40 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, Mar 21, 2007, Stephen Farrell wrote: > >Hi, > >Peter Lovell wrote: >> On Wed, Mar 21, 2007, Stephen Farrell wrote: >> >>> >>> Scott Burleigh wrote: >>>> This seems pretty unambiguous to me; I think we're still on safe ground >>>> with NULL-terminated strings. >>> I think that's only because we restrict to URIs and not IRIs though, >>> right? (I'll check with someone here at the IETF.) >>> >>> S. >> >> We're OK with NULL-terminated strings because section 3.5 says ... >> >> Each endpoint ID conveyed in any bundle block takes the form >> of a Uniform Resource Identifier (URI; [RFC3986]). >> >> However, things then become confusing at the end of that section, which >> says ... >> >> Note that, although the endpoint IDs conveyed in bundle blocks are >> expressed as URIs, implementations of the BP service interface may >> support expression of endpoint IDs in some internationalized manner >> (e.g., IRIs; see RFC 3987). >> >> I take this to mean that IRIs, if supported, must be transformed IRI -> >> URI [as described in rfc3987] before sending. > >I checked with "someone who knows" (Paul Hoffman) and it seems >we're ok with IRIs too - as far as he knows no existing scheme >embeds NULLs inside an IRI and it'd break other protocols first >(he said HTTP but I'm not sure about that - that might use a >CRLF to terminate). > >S. > So I might well ask why we have "length" fields for the EIDs in security blocks? Couldn't we simplify those by handling them the same way as in the primary block? Cheers.....Peter Received: from smtp.ietf68.org (egon.ietf68.org [130.129.5.7]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2LEo3Y28434 for ; Wed, 21 Mar 2007 06:50:03 -0800 Received: from [130.129.20.89] (dhcp-1459.ietf68.org [130.129.20.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ietf68.org (Postfix) with ESMTP id 1EBC35005F; Wed, 21 Mar 2007 15:50:02 +0100 (CET) Message-ID: <4601466F.80501@cs.tcd.ie> Date: Wed, 21 Mar 2007 14:51:27 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Peter Lovell CC: Scott Burleigh , dtn interest Subject: Re: [dtn-interest] questions re bundle dictionary and flags References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> <46007D70.3050706@jpl.nasa.gov> <4600AC55.5090908@jpl.nasa.gov> <4600DB4B.2090808@cs.tcd.ie> <20070321134626.1384641441@nemo.columbia.sparta.com> In-Reply-To: <20070321134626.1384641441@nemo.columbia.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi, Peter Lovell wrote: > On Wed, Mar 21, 2007, Stephen Farrell wrote: > >> >> Scott Burleigh wrote: >>> This seems pretty unambiguous to me; I think we're still on safe ground >>> with NULL-terminated strings. >> I think that's only because we restrict to URIs and not IRIs though, >> right? (I'll check with someone here at the IETF.) >> >> S. > > We're OK with NULL-terminated strings because section 3.5 says ... > > Each endpoint ID conveyed in any bundle block takes the form > of a Uniform Resource Identifier (URI; [RFC3986]). > > However, things then become confusing at the end of that section, which > says ... > > Note that, although the endpoint IDs conveyed in bundle blocks are > expressed as URIs, implementations of the BP service interface may > support expression of endpoint IDs in some internationalized manner > (e.g., IRIs; see RFC 3987). > > I take this to mean that IRIs, if supported, must be transformed IRI -> > URI [as described in rfc3987] before sending. I checked with "someone who knows" (Paul Hoffman) and it seems we're ok with IRIs too - as far as he knows no existing scheme embeds NULLs inside an IRI and it'd break other protocols first (he said HTTP but I'm not sure about that - that might use a CRLF to terminate). S. Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2LDkYY27888 for ; Wed, 21 Mar 2007 05:46:34 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2LDkSbQ003495; Wed, 21 Mar 2007 08:46:28 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2LDkSLr018713; Wed, 21 Mar 2007 08:46:29 -0500 Received: from [157.185.80.152] ([157.185.80.152]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 09:46:28 -0400 From: "Peter Lovell" To: "Stephen Farrell" , "Scott Burleigh" Cc: "dtn interest" Subject: Re(2): [dtn-interest] questions re bundle dictionary and flags Date: Wed, 21 Mar 2007 09:46:26 -0400 Message-Id: <20070321134626.1384641441@nemo.columbia.sparta.com> In-Reply-To: <4600DB4B.2090808@cs.tcd.ie> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> <46007D70.3050706@jpl.nasa.gov> <4600AC55.5090908@jpl.nasa.gov> <4600DB4B.2090808@cs.tcd.ie> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 13:46:28.0241 (UTC) FILETIME=[53375810:01C76BBF] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Wed, 21 Mar 2007 08:46:28 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, Mar 21, 2007, Stephen Farrell wrote: > > >Scott Burleigh wrote: >> This seems pretty unambiguous to me; I think we're still on safe ground >> with NULL-terminated strings. > >I think that's only because we restrict to URIs and not IRIs though, >right? (I'll check with someone here at the IETF.) > >S. We're OK with NULL-terminated strings because section 3.5 says ... Each endpoint ID conveyed in any bundle block takes the form of a Uniform Resource Identifier (URI; [RFC3986]). However, things then become confusing at the end of that section, which says ... Note that, although the endpoint IDs conveyed in bundle blocks are expressed as URIs, implementations of the BP service interface may support expression of endpoint IDs in some internationalized manner (e.g., IRIs; see RFC 3987). I take this to mean that IRIs, if supported, must be transformed IRI -> URI [as described in rfc3987] before sending. Cheers.....Peter Received: from brev.sics.se (brev.sics.se [193.10.64.200]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2LDEUY27648 for ; Wed, 21 Mar 2007 05:14:30 -0800 Received: from www.sics.se (jenny.sics.se [193.10.64.99]) by brev.sics.se (8.12.8/8.12.8) with ESMTP id l2LDER8e002010 for ; Wed, 21 Mar 2007 14:14:28 +0100 Received: from dutibh.st.ewi.tudelft.nl ([130.161.159.75]) (SquirrelMail authenticated user muneeb) by www.sics.se with HTTP; Wed, 21 Mar 2007 14:14:28 +0100 (CET) Message-ID: <48204.130.161.159.75.1174482868.squirrel@www.sics.se> Date: Wed, 21 Mar 2007 14:14:28 +0100 (CET) From: muneeb@sics.se To: dtn-interest@mailman.dtnrg.org User-Agent: SquirrelMail/1.4.4-1.FC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new Subject: [dtn-interest] SIGCOMM NSDR'07: Deadline approaching Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Kindly note that the submission deadline for "ACM SIGCOMM Workshop on Networked Systems for Developing Regions 2007" is in less than a month (April 6th): =================================================================================== CALL FOR PAPERS ACM SIGCOMM Workshop on Networked Systems for Developing Regions (NSDR 2007) (with ACM SIGCOMM 2007) Kyoto Japan, Monday 27th August, 2007. http://nsdr.dritte.org =================================================================================== The ACM SIGCOMM Workshop on Networked Systems for Developing Regions (NSDR) will provide a venue for researchers to propose and discuss ideas and to participate in the sustainable development and deployment of Internet and communication technologies for developing countries. Benefits of the Internet and communication technologies are limited to a fraction of the world's population e.g. according to a 2006 survey Internet penetration in North America is 69.1% of population compared to 3.6% for Africa and 10.8% for Asia. Cost factors, low literacy, and limited access to power and bandwidth in developing regions seem to suggest that there is a need for communication technology research specifically aimed to meet the special needs of developing regions. The great and diverse needs of developing regions (e.g. economic problems, social issues) call for a multi-disciplinary research agenda. However, the focus of NSDR is on communication and networking aspects of developing regions research (e.g. communication infrastructure in rural areas, systems build using such infrastructure that solve some specific problem). PAPERS We encourage submission of early works (position papers) describing interesting, original, previously unpublished ideas pertaining to networked systems for developing regions, which: * propose new research directions, * target a specific application, * have the potential to significantly enhance the design and sustainable deployment of networked systems in developing regions, * or could generate lively debate at the workshop. Areas of interest include, but are not limited to: * Delay Tolerant Networking: delay-tolerant Internet access in developing regions, DTN routing over wireless rural links * Rural Wireless: long-distance 802.11, WiMaX solutions, directional antennas * Low-cost Computing Devices: low-cost end-user devices which constitute the network, mobile phones as primary computing devices, task-specific devices * Sensor Networks: sensor-nets designed specifically for developing regions * Power-Efficient Systems: power-efficient computing architectures, power-efficient network infrastructure, power-efficient mobile systems * Sustainable Deployment: pricing models for sustainable deployment of communication infrastructure * Applications: healthcare, disaster management, education SUBMISSION GUIDELINES Submissions must be no greater than 6 pages (six pages) in length (including figures and references), must be a PDF file, and must follow the formatting guidelines at http://www.sigcomm.org/sigcomm2007/workshop-psg.html. Submissions that deviate from these guidelines will be rejected without consideration. Reviews will be SINGLE-BLIND: authors name and affiliation should be included in the submission. All submissions will be handled electronically via EDAS (http://edas.info/). Authors of accepted papers are expected to present their papers at the workshop. Submissions must be original work not under review at any other workshop, conference, or journal. IMPORTANT DATES Submission: Fri, 6th April, 2007 Notification: Fri, 18th May, 2007 Camera-ready: Wed, 13th June, 2007 Workshop: Mon, 27th Aug, 2007 PROGRAM COMMITTEE Eric Brewer, UC Berkeley, USA (PC Co-Chair) Umar Saif, LUMS, Pakistan (PC Co-Chair) Jon Crowcroft, Cambridge, UK Steve Ward, M.I.T, USA Andrew Campbell, Dartmouth College, USA Kentaro Toyama, Microsoft Research, India Zeeshan Syed, M.I.T, USA S. Keshav, Unv. of Waterloo, Canada Rahul Tongia, CMU, USA Koen Langendoen, TU Delft, Netherlands Thiemo Voigt, SICS, Sweden Keiko Okawa, Keio University, Japan Bhaskaran Raman, IIT Kanpur, India Kaustubh Phanse, Uppsala Unv., Sweden Mike Hazas, Lancaster Unv., UK Adam Dunkels, SICS, Sweden Jan Beutel, ETH Zurich, Switzerland (Publications Chair) Joseph Polastre, Moteiv, USA (Industry Chair) Muneeb Ali, TU Delft, Netherlands (Publicity Chair) NSDR'07 papers will be published by ACM in the *joint* workshops proceedings of SIGCOMM'07 (note this is different from the SIGCOMM'07 conference proceedings)and will be indexed by the ACM Digital Library. Regards, Umar Saif, Eric Brewer, and Muneeb Ali, ACM NSDR'07 organizers Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2LBZFY26654 for ; Wed, 21 Mar 2007 03:35:15 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2LBZ9VD030440; Wed, 21 Mar 2007 06:35:10 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2LBZ9fC014542; Wed, 21 Mar 2007 06:35:10 -0500 Received: from [157.185.80.152] ([157.185.80.152]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 07:35:09 -0400 From: "Peter Lovell" To: "Stephen Farrell" , "Scott Burleigh" Cc: "dtn interest" Subject: Re(2): [dtn-interest] questions re bundle dictionary and flags Date: Wed, 21 Mar 2007 07:35:09 -0400 Message-Id: <20070321113509.2028999551@nemo.columbia.sparta.com> In-Reply-To: <46000680.5020105@cs.tcd.ie> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <45FF1D3F.5090100@jpl.nasa.gov> <20070320020710.2058155815@127.0.0.1> <4600034A.1000801@jpl.nasa.gov> <46000680.5020105@cs.tcd.ie> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 11:35:09.0288 (UTC) FILETIME=[FAFE8680:01C76BAC] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Wed, 21 Mar 2007 06:35:10 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Tue, Mar 20, 2007, Stephen Farrell wrote: > >Scott Burleigh wrote: >> What I haven't yet thought much about is how this would interact with >> security. CBHE compression would nominally want to be applied after the >> bundle security blocks are created, so signatures and such would have >> been generated from the uncompressed form of the bundle with all EIDs in >> uncompressed form (that is, textual URIs in the dictionary), so we need >> to be able to decompress/regenerate the bundle into that exact form in >> order for bundle security to work. Which might mean that we need some >> sort of a convention for dictionary structure in order to get CBHE and >> BSP to coexist peacefully. > >Yes. We do need that. I think you could require (in the CBHE spec) that >implementations have a way to map from compressed EIDs back - but that >can be local, at least for the cases you want, right? If I read it correctly, CBHE does this already. Compression is done at the outgoing CL and then the receiving CL decompresses. CBHE spec section 2.2 says ... This compression method is applied at the convergence layer: the transmitting convergence-layer adaptation compresses the primary block as shown above, and upon reception the receiving convergence- layer adaptation de-compresses the block by simply reversing the process. Cheers.....Peter Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2L9KPY25740 for ; Wed, 21 Mar 2007 01:20:25 -0800 Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.22.0.58]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1HTwzI-0004Hq-Q4; Wed, 21 Mar 2007 10:20:08 +0100 Message-ID: <4600F8C7.6050203@cs.uni-goettingen.de> Date: Wed, 21 Mar 2007 10:20:07 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: hipsec-rg@listserv.cybertrust.com, mobopts@irtf.org, dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Subject: [dtn-interest] Final CFP for MobiArch at SIGCOMM'07: submission deadline extension to April 3 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Dear colleagues, Please find below a CFP for the MobiArch'07 workshop at SIGCOMM'07 and your consideration of submissions and further dissemination are highly appreciated. We apologize if you receive multiple copies of this CFP. Yours sincerely, MobiArch'07 organizers Important dates: Registration of authors and abstract: (extended to) March 27, 2007 Submission deadline: (extended to) April 3, 2007 (FIRM!) Notification of acceptance: May 22, 2007 Camera ready version due: June 17, 2007 Workshop date: Monday, August 27, 2007 -------------------------------------------------------------------- The Second International Workshop on Mobility in the Evolving Internet Architecture (MobiArch 2007) Kyoto, Japan, August 27, 2007 Sponsored by ACM SIGCOMM In-Cooperation with ACM SIGMOBILE (to be held with ACM SIGCOMM 2007, August 27-31, 2007) http://user.informatik.uni-goettingen.de/~mobiarch/2007 -------------------------------------------------------------------- Call for Papers: =============== With the recent development of technologies in wireless access and mobile devices, user, terminal, and network mobility has become an indispensable component of today's Internet vision, and it is likely to continue in the near future, while affecting the whole architectural design of the future Internet. Yet, issues like efficient mobility management and optimization, locator-identifier split, multihoming, security, and related operational/deployment concerns are still in their early stages of development. Moreover, the Internet architecture, its end-to-end principles, and business models will require rethinking due to the massive penetration of mobility into the Internet. MobiArch'07 welcomes submissions, from both researchers and practitioners, in exploration of recent advances in architectures, protocols, and experiences with emerging technologies on wireless and mobility over the Internet, with an emphasis on wireless infrastructures and mobility patterns for mobility support, new mobility protocols, service discovery, routing and location management, mobile network performance evaluation and modeling, multi-homing, security, architectural impacts and deployment considerations. Topics of Interest: ================== Topics of MobiArch’07 cover all aspects of architectural issues and system support for wireless and mobility in the Internet, including but not limited to: - Impacts of new wireless technologies/services and mobility patterns on the Internet architecture - Architectures and protocols for mobility support in the Internet, ranging from approaches in link, network, transport to session/application layers and cross-layer design - Location management, positioning and data management systems for wireless and mobility - Routing and addressing, including locator/identifier split issues and their impacts to the Internet architecture - IP multihoming including flow distribution and load sharing for wireless and mobility - Performance evaluation, experimentation and modeling of mobility in the Internet - Accounting, access control, security and privacy issues and impacts to Internet architecture - Economic, scalability and deployment issues of mobility infrastructure design - Mechanisms and issues with connecting developing regions into the Internet Following the success of MobiArch'06, the MobiArch'07 workshop will be a single-track one-day workshop. Early stages, position papers, systems and measurement papers will be particularly welcome. The proceedings will be published by the ACM and ACM digital library. Submissions: =========== Submissions must be made to MobiArch'07 EDAS entry: http://edas.info/5238, following the guidelines in MobiArch'07 webpage: http://user.informatik.uni-goettingen.de/~mobiarch/2007 PROGRAM CO-CHAIRS ================= Xiaoming Fu, University of Goettingen (Germany) Katherine Guo, Bell Labs (USA) Sue Moon, KAIST (Korea) Ryuji Wakikawa, Keio University (Japan) PROGRAM COMMITTEE ================= Rui Aguiar, Universidade de Aveiro (Portugal) Jari Arkko, Ericsson (Finland) Song Chong, KAIST (Korea) Lars Eggert, NEC Europe Labs (Germany) Joseph Evans, U. Kansas (USA) Serge Fdida, University Pierre & Marie Curie (Paris 6) (France) Ivano Guardini, Telecom Italia Lab (IT) Seung-Jae Han, Yonsei U (Korea) Rajeev Koodli, Nokia Research Center (USA) Stefan Mangold, Swisscom (Switzerland) Thomas Noel, Universite Strasbourg (France) Joerg Ott, Helsinki U of Techology (Finland) Charles Perkins, Nokia Research Center (USA) Injong Rhee, NC State University (USA) Henning Schulzrinne, Columbia U. (USA) Peter Steenkiste, CMU (USA) Hideaki Sunahara, NARA Inst. of Sci. & Tech. (Japan) Fumio Teraoka, Keio U. (Japan) Hannes Tschofenig, Siemens (Germany) Andras Veres, Ericsson (Hungary) Kenichi Yamazaki, NTT Docomo (Japan) Lixia Zhang, UCLA (USA) Yongguang Zhang, Microsoft Research Asia (China) PUBLICITY CHAIR =============== Jon Crowcroft, University of Cambridge (UK) QUESTIONS ========= Please consult the Program Co-Chairs (mobiarch@informatik.uni-goettingen.de) if you are uncertain whether your paper falls within the scope of the workshop. Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2L8RVY25396 for ; Wed, 21 Mar 2007 00:27:31 -0800 Received: from [IPv6:2001:df8:0:16:a4a4:7ce7:534d:8e11] ([IPv6:2001:df8:0:16:a4a4:7ce7:534d:8e11]) (authenticated bits=0) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2L8R59T018733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Mar 2007 09:27:27 +0100 (CET) Message-ID: <4600EC4F.6070005@informatik.uni-bremen.de> Date: Wed, 21 Mar 2007 09:26:55 +0100 From: Dirk Kutscher Organization: TZI, =?ISO-8859-1?Q?Universit=E4t_Bremen?= User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Support for DTN in mobile ad hoc networks References: <1172872263.45e89c47da1cd@webmailapp3.cc.utexas.edu> In-Reply-To: <1172872263.45e89c47da1cd@webmailapp3.cc.utexas.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: vrbaba@mail.utexas.edu wrote: > I am interested in performance of DTN like mobile ad hoc networks. I was > wondering if there are any current simulation environments that I can use to > run some mobility scenarios within the next two months? > > Do you know of anyone who has developed protocols for Delay tolerant mobile ad > hoc networks and done sucessful simulations using ns2, omnet++, or others? > > Ideally, I would like to know those protocols, and try to duplicate their > results to verify a working environment, and possibly make some modifications > of my own to the routing algorithm. Varun, for our CHANTS-2006 paper "Integrating DTN and MANET Routing", we have built an emulation environment based on nsemulation and Xen. https://prj.tzi.org/cgi-bin/trac.cgi/wiki/Kasuari The paper, which describes extensions to AODV to help with DTN network topology discovery, is also referenced on that website. The filesystem image for the virtual guest nodes already comes with DTN2 and AODV-UU. Hope this helps, Dirk Received: from smtp.ietf68.org (egon.ietf68.org [130.129.5.7]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2L7CwY24794 for ; Tue, 20 Mar 2007 23:12:58 -0800 Received: from [10.0.0.254] (dhcp-4009.ietf68.org [130.129.64.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ietf68.org (Postfix) with ESMTP id 46F7B5004C; Wed, 21 Mar 2007 08:12:57 +0100 (CET) Message-ID: <4600DB4B.2090808@cs.tcd.ie> Date: Wed, 21 Mar 2007 07:14:19 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Scott Burleigh CC: dtn interest Subject: Re: [dtn-interest] questions re bundle dictionary and flags References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> <46007D70.3050706@jpl.nasa.gov> <4600AC55.5090908@jpl.nasa.gov> In-Reply-To: <4600AC55.5090908@jpl.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Scott Burleigh wrote: > This seems pretty unambiguous to me; I think we're still on safe ground > with NULL-terminated strings. I think that's only because we restrict to URIs and not IRIs though, right? (I'll check with someone here at the IETF.) S. Received: from mta16.adelphia.net (mta16.mail.adelphia.net [68.168.78.211]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2L3ruY23580 for ; Tue, 20 Mar 2007 19:53:56 -0800 Received: from [127.0.0.1] (really [76.173.246.97]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20070321035350.XQZM2765.mta16.adelphia.net@[127.0.0.1]> for ; Tue, 20 Mar 2007 23:53:50 -0400 Message-ID: <4600AC55.5090908@jpl.nasa.gov> Date: Tue, 20 Mar 2007 20:53:57 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] questions re bundle dictionary and flags References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> <46007D70.3050706@jpl.nasa.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Scott, Keith L. wrote: > I'm going from section 2 of 3986. The way I interpret these, the first > paragraph sort of supports the position that the things that make up > the SSP might be stored/used differently (e.g. non-ASCII), whereas the > third paragraph seems to refute it. > > --keith > > 2. Characters > > The URI syntax provides a method of encoding data, presumably for > the > sake of identifying a resource, as a sequence of characters. The > URI > characters are, in turn, frequently encoded as octets for transport > or presentation. This specification does not mandate any particular > character encoding for mapping between URI characters and the octets > used to store or transmit those characters. When a URI appears in a > protocol element, the character encoding is defined by that > protocol; > without such a definition, a URI is assumed to be in the same > character encoding as the surrounding text. I see what you mean, but I think that the words "character encoding" here are meant to mean alternatives to ASCII, such as EBCDIC. The RFC seems to me to be pretty clear that a URI is a sequence of "characters", not a sequence of octets of arbitrary value. And I think what is meant by "character" is what we all think of as a character: a printable letter, digit, punctuation mark, arithmetic symbol, etc.; the third paragraph seems to make this pretty clear. > The ABNF notation defines its terminal values to be non-negative > integers (codepoints) based on the US-ASCII coded character set > [ASCII]. Because a URI is a sequence of characters, ....."a sequence of characters"... > we must invert that relation in order to understand the URI syntax. Therefore, the > integer values used by the ABNF must be mapped back to their > corresponding characters via US-ASCII in order to complete the > syntax > rules. > > A URI is composed from a limited set of characters consisting of > digits, letters, and a few graphic symbols. This seems pretty unambiguous to me; I think we're still on safe ground with NULL-terminated strings. Scott > A reserved subset of those characters may be used to delimit syntax components within a > URI while the remaining characters, including both the unreserved > set > and those reserved characters not acting as delimiters, define each > component's identifying data. > > --keith > >> -----Original Message----- >> From: dtn-interest-admin@mailman.dtnrg.org >> [mailto:dtn-interest-admin@mailman.dtnrg.org] On Behalf Of >> Scott Burleigh >> Sent: Tuesday, March 20, 2007 8:34 PM >> To: dtn interest >> Subject: Re: [dtn-interest] questions re bundle dictionary and flags >> >> Scott, Keith L. wrote: >>> Do we really depend on the scheme-specific parts being >> NULL-terminated? >>> >> Currently we do. There's no other mechanism in the >> dictionary for detecting the end of a scheme name or the end >> of an SSP. >>> A long time ago we'd considered other schemes, like GUID >> schemes where >>> the SSP was just a number. If the SSP of such schemes >> might be stored >>> as an integer (shorter than its ASCII representation) then >> NULLs might >>> show up in the middle of SSPs. The URI RFC seems to >> indicate that the >>> stored/'use' representation of the scheme-specific part of the URI >>> need not be ASCII. >>> >> As far as I know, nobody is planning to use this sort of >> representation in an EID. If they did then you are right, it >> would be entirely possible to have a NULL in the middle of an >> SSP, and a lot of code would break. Can you cite the >> language in the URI RFC that would allow the SSP of a URI to >> be something other than text? I thought we had considered >> all this pretty carefully and concluded that NULL-terminating >> the strings in the dictionary would work okay. >> >> Scott >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@mailman.dtnrg.org >> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest >> > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2L0hDY22329 for ; Tue, 20 Mar 2007 16:43:13 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l2L0hDmj001951 for ; Tue, 20 Mar 2007 20:43:13 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 1FB7EBF7D for ; Tue, 20 Mar 2007 20:43:13 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l2L0hCnl001939; Tue, 20 Mar 2007 20:43:12 -0400 Received: from IMCSRV1.MITRE.ORG ([129.83.20.158]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 20:43:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dtn-interest] questions re bundle dictionary and flags Date: Tue, 20 Mar 2007 20:43:11 -0400 Message-ID: In-Reply-To: <46007D70.3050706@jpl.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] questions re bundle dictionary and flags Thread-Index: AcdrUOgsX9LSbgGQQ9eqpgb9TSITLwAAI0Ig References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> <46007D70.3050706@jpl.nasa.gov> From: "Scott, Keith L." To: "Scott Burleigh" , "dtn interest" X-OriginalArrivalTime: 21 Mar 2007 00:43:12.0725 (UTC) FILETIME=[E7B4B050:01C76B51] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id l2L0hDY22329 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: I'm going from section 2 of 3986. The way I interpret these, the first paragraph sort of supports the position that the things that make up the SSP might be stored/used differently (e.g. non-ASCII), whereas the third paragraph seems to refute it. --keith 2. Characters The URI syntax provides a method of encoding data, presumably for the sake of identifying a resource, as a sequence of characters. The URI characters are, in turn, frequently encoded as octets for transport or presentation. This specification does not mandate any particular character encoding for mapping between URI characters and the octets used to store or transmit those characters. When a URI appears in a protocol element, the character encoding is defined by that protocol; without such a definition, a URI is assumed to be in the same character encoding as the surrounding text. The ABNF notation defines its terminal values to be non-negative integers (codepoints) based on the US-ASCII coded character set [ASCII]. Because a URI is a sequence of characters, we must invert that relation in order to understand the URI syntax. Therefore, the integer values used by the ABNF must be mapped back to their corresponding characters via US-ASCII in order to complete the syntax rules. A URI is composed from a limited set of characters consisting of digits, letters, and a few graphic symbols. A reserved subset of those characters may be used to delimit syntax components within a URI while the remaining characters, including both the unreserved set and those reserved characters not acting as delimiters, define each component's identifying data. --keith > -----Original Message----- > From: dtn-interest-admin@mailman.dtnrg.org > [mailto:dtn-interest-admin@mailman.dtnrg.org] On Behalf Of > Scott Burleigh > Sent: Tuesday, March 20, 2007 8:34 PM > To: dtn interest > Subject: Re: [dtn-interest] questions re bundle dictionary and flags > > Scott, Keith L. wrote: > > Do we really depend on the scheme-specific parts being > NULL-terminated? > > > Currently we do. There's no other mechanism in the > dictionary for detecting the end of a scheme name or the end > of an SSP. > > A long time ago we'd considered other schemes, like GUID > schemes where > > the SSP was just a number. If the SSP of such schemes > might be stored > > as an integer (shorter than its ASCII representation) then > NULLs might > > show up in the middle of SSPs. The URI RFC seems to > indicate that the > > stored/'use' representation of the scheme-specific part of the URI > > need not be ASCII. > > > As far as I know, nobody is planning to use this sort of > representation in an EID. If they did then you are right, it > would be entirely possible to have a NULL in the middle of an > SSP, and a lot of code would break. Can you cite the > language in the URI RFC that would allow the SSP of a URI to > be something other than text? I thought we had considered > all this pretty carefully and concluded that NULL-terminating > the strings in the dictionary would work okay. > > Scott > > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > Received: from nmta3.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.108]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2L0XwY22257 for ; Tue, 20 Mar 2007 16:33:58 -0800 Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by nmta3.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2L0XrL0017276 for ; Tue, 20 Mar 2007 17:33:53 -0700 Received: from [127.0.0.1] (dhcp-79-22-247.jpl.nasa.gov [137.79.22.247]) by xmta2.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2L0XqK3010511 for ; Tue, 20 Mar 2007 17:33:53 -0700 Message-ID: <46007D70.3050706@jpl.nasa.gov> Date: Tue, 20 Mar 2007 17:33:52 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] questions re bundle dictionary and flags References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-247.jpl.nasa.gov [137.79.22.247] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Scott, Keith L. wrote: > Do we really depend on the scheme-specific parts being NULL-terminated? > Currently we do. There's no other mechanism in the dictionary for detecting the end of a scheme name or the end of an SSP. > A long time ago we'd considered other schemes, like GUID schemes where > the SSP was just a number. If the SSP of such schemes might be stored > as an integer (shorter than its ASCII representation) then NULLs might > show up in the middle of SSPs. The URI RFC seems to indicate that the > stored/'use' representation of the scheme-specific part of the URI need > not be ASCII. > As far as I know, nobody is planning to use this sort of representation in an EID. If they did then you are right, it would be entirely possible to have a NULL in the middle of an SSP, and a lot of code would break. Can you cite the language in the URI RFC that would allow the SSP of a URI to be something other than text? I thought we had considered all this pretty carefully and concluded that NULL-terminating the strings in the dictionary would work okay. Scott Received: from smtp-mclean.mitre.org (smtpproxy2.mitre.org [192.80.55.71]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2L09RY22040 for ; Tue, 20 Mar 2007 16:09:28 -0800 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l2L09Rd1003257 for ; Tue, 20 Mar 2007 20:09:27 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id E793F1BD80 for ; Tue, 20 Mar 2007 20:09:26 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l2L09QPL003240; Tue, 20 Mar 2007 20:09:26 -0400 Received: from IMCSRV1.MITRE.ORG ([129.83.20.158]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 20:09:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Re(8): [dtn-interest] questions re bundle dictionary and flags Date: Tue, 20 Mar 2007 20:09:24 -0400 Message-ID: In-Reply-To: <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re(8): [dtn-interest] questions re bundle dictionary and flags Thread-Index: AcdrFAN8jLnx5FiTRrGgEhKZhGD5ugAOKkgg References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> From: "Scott, Keith L." To: "Michael Demmer" , "Peter Lovell" Cc: "Scott Burleigh" , "dtn interest" , "Symington, Susan F." X-OriginalArrivalTime: 21 Mar 2007 00:09:25.0985 (UTC) FILETIME=[2FACB510:01C76B4D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id l2L09RY22040 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Do we really depend on the scheme-specific parts being NULL-terminated? A long time ago we'd considered other schemes, like GUID schemes where the SSP was just a number. If the SSP of such schemes might be stored as an integer (shorter than its ASCII representation) then NULLs might show up in the middle of SSPs. The URI RFC seems to indicate that the stored/'use' representation of the scheme-specific part of the URI need not be ASCII. --keith > -----Original Message----- > From: dtn-interest-admin@mailman.dtnrg.org > [mailto:dtn-interest-admin@mailman.dtnrg.org] On Behalf Of > Michael Demmer > Sent: Tuesday, March 20, 2007 1:19 PM > To: Peter Lovell > Cc: Scott Burleigh; dtn interest; Symington, Susan F. > Subject: Re: Re(8): [dtn-interest] questions re bundle > dictionary and flags > > > Jon's situation is an interesting one and he's correct that it will > > happen frequently. > > > > Much of the difficulty comes from the fact that EID references (the > > pair of 16-bit offsets) are present in many blocks. An alternative > > approach would be to have these references in a table at > the start of > > the dictionary. So the dictionary would be a table followed > by the EID > > data strings. The various places which presently have an "EID > > reference" > > would instead have a "dictionary index", a small integer > specifying an > > entry in the table. > > > > This has an extra level of lookup (small additional > overhead) but has > > the big advantage that the internal layout of the > dictionary data is > > completely opaque. > > Thinking about this more, it occurs to me that we could > achieve the benefits of Peter's proposal without requiring > the index and extra layer of indirection at the start of the > dictionary. > > Suppose we change dictionary references in all blocks to > indices instead of offsets, as Peter suggested. A BPA can > easily calculate the mapping of a dictionary index to the > correct offset in the dictionary byte array by scanning the > contents of the dictionary when it arrives, and keeping track > of the locations of all the NULL terminators. > > That way even if the custodian (or other such fields) change > from hop to hop, the index of the particular dictionary > entries may not need to change, and thus blocks need not > depend on them. > > We still would have the prior issue of determining when a BPA > is allowed to remove entries from a dictionary for > compression purposes, as mentioned earlier in this thread. > > -mike > > > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2KL6jY20753 for ; Tue, 20 Mar 2007 13:06:45 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2KL6aYU002222; Tue, 20 Mar 2007 16:06:37 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2KL6XLo025055; Tue, 20 Mar 2007 16:06:34 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 17:06:33 -0400 From: "Peter Lovell" To: "Stephen Farrell" , "Scott Burleigh" Cc: "dtn interest" Subject: Re(2): [dtn-interest] questions re bundle dictionary and flags Date: Tue, 20 Mar 2007 17:06:32 -0400 Message-Id: <20070320210632.1066823907@127.0.0.1> In-Reply-To: <46000680.5020105@cs.tcd.ie> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <45FF1D3F.5090100@jpl.nasa.gov> <20070320020710.2058155815@127.0.0.1> <4600034A.1000801@jpl.nasa.gov> <46000680.5020105@cs.tcd.ie> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2007 21:06:33.0519 (UTC) FILETIME=[A39343F0:01C76B33] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 20 Mar 2007 16:06:37 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Tue, Mar 20, 2007, Stephen Farrell wrote: > > >Scott Burleigh wrote: >> What I haven't yet thought much about is how this would interact with >> security. CBHE compression would nominally want to be applied after the >> bundle security blocks are created, so signatures and such would have >> been generated from the uncompressed form of the bundle with all EIDs in >> uncompressed form (that is, textual URIs in the dictionary), so we need >> to be able to decompress/regenerate the bundle into that exact form in >> order for bundle security to work. Which might mean that we need some >> sort of a convention for dictionary structure in order to get CBHE and >> BSP to coexist peacefully. > >Yes. We do need that. I think you could require (in the CBHE spec) that >implementations have a way to map from compressed EIDs back - but that >can be local, at least for the cases you want, right? I don't know if >there're any cases of using CBHE where the verifier has to be able to >check a signature on a bundle that involves a random EID, but if there >are then CBHE has to define a probably optional compressed dictionary. > Signatures will always be on the uncompressed bundle and will work fine as long as the decompression is _exactly_ the inverse of the compression. What won't work is compressing an encrypted block. If the block has confidentiality applied to it, then no compression is possible. The index + dictionary idea does give the benefit of compression in this case, but unfortunately the EID strings aren't encrypted. Regards.....Peter Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2KKotY20623 for ; Tue, 20 Mar 2007 12:50:55 -0800 Received: from [128.32.131.196] (dhcp-131-196.EECS.Berkeley.EDU [128.32.131.196]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.0/8.13.5) with ESMTP id l2KKoqnj019379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Mar 2007 13:50:53 -0700 (PDT) In-Reply-To: <20070320204524.1936152011@127.0.0.1> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> <20070320204524.1936152011@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Scott Burleigh , dtn interest , Susan Content-Transfer-Encoding: 7bit From: Michael Demmer Subject: Re: Re(10): [dtn-interest] questions re bundle dictionary and flags X-Applemailsentby: demmer Date: Tue, 20 Mar 2007 13:50:53 -0700 To: Peter Lovell X-Mailer: Apple Mail (2.752.3) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: > I had pondered an approach like the one you mention but felt that > there > would be complications. > > The main one is that we can't just change the data "behind" or > pointed- > at by an index, if that is what you were suggesting. Some entries will > have multiple references to them and a change might be intended to > apply > to one instance only. So we'd have to add the new one and then see if > the old one compresses out. Assuming you have some extension blocks in the bundle which are not grokked by the particular implementation, then yes. But I don't see how this is different in your scheme, unless I don't completely understand your proposal. > A second reason is that we compress schemes and the ssps > separately. We > could no longer do that and have a single index. We could have two > index > values, though. Not a big deal. I assumed two index values, one for each of scheme and ssp. > One related possibility which has occurred to me, relating to > compression, is to have the general block processor code be minimally > aware of security blocks, just enough to extract EIDs. This would > not be > mandatory, but required only if the implementation wanted to compress > the dictionary. I'm not a fan of this approach -- it special cases the security blocks, but the same problem would exist for any other blocks that are defined, so we'd need some mechanism of handling them. It seems to me that if the implementation is aware enough of the structure of security blocks to identify the EIDs, then the node is said to understand the block for the purposes of the BPA. -mike Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2KKjiY20575 for ; Tue, 20 Mar 2007 12:45:44 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2KKjUSb000850; Tue, 20 Mar 2007 15:45:30 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2KKjRWt023828; Tue, 20 Mar 2007 15:45:29 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 16:45:26 -0400 From: "Peter Lovell" To: "Michael Demmer" Cc: "Scott Burleigh" , "dtn interest" , Susan Subject: Re(10): [dtn-interest] questions re bundle dictionary and flags Date: Tue, 20 Mar 2007 16:45:24 -0400 Message-Id: <20070320204524.1936152011@127.0.0.1> In-Reply-To: <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2007 20:45:26.0347 (UTC) FILETIME=[B04829B0:01C76B30] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 20 Mar 2007 15:45:33 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Tue, Mar 20, 2007, Michael Demmer wrote: >> Jon's situation is an interesting one and he's correct that it will >> happen frequently. >> >> Much of the difficulty comes from the fact that EID references (the >> pair >> of 16-bit offsets) are present in many blocks. An alternative approach >> would be to have these references in a table at the start of the >> dictionary. So the dictionary would be a table followed by the EID >> data >> strings. The various places which presently have an "EID reference" >> would instead have a "dictionary index", a small integer specifying an >> entry in the table. >> >> This has an extra level of lookup (small additional overhead) but has >> the big advantage that the internal layout of the dictionary data is >> completely opaque. > >Thinking about this more, it occurs to me that we could achieve the >benefits of Peter's proposal without requiring the index and extra >layer of indirection at the start of the dictionary. > >Suppose we change dictionary references in all blocks to indices >instead of offsets, as Peter suggested. A BPA can easily calculate >the mapping of a dictionary index to the correct offset in the >dictionary byte array by scanning the contents of the dictionary when >it arrives, and keeping track of the locations of all the NULL >terminators. > >That way even if the custodian (or other such fields) change from hop >to hop, the index of the particular dictionary entries may not need >to change, and thus blocks need not depend on them. > >We still would have the prior issue of determining when a BPA is >allowed to remove entries from a dictionary for compression purposes, >as mentioned earlier in this thread. > >-mike > > Hi Mike, I had pondered an approach like the one you mention but felt that there would be complications. The main one is that we can't just change the data "behind" or pointed- at by an index, if that is what you were suggesting. Some entries will have multiple references to them and a change might be intended to apply to one instance only. So we'd have to add the new one and then see if the old one compresses out. A second reason is that we compress schemes and the ssps separately. We could no longer do that and have a single index. We could have two index values, though. Not a big deal. One related possibility which has occurred to me, relating to compression, is to have the general block processor code be minimally aware of security blocks, just enough to extract EIDs. This would not be mandatory, but required only if the implementation wanted to compress the dictionary. Cheers.....Peter Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2KHIYY19041 for ; Tue, 20 Mar 2007 09:18:34 -0800 Received: from [10.212.2.201] ([12.46.129.72]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.0/8.13.5) with ESMTP id l2KHIWmG014677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Mar 2007 10:18:33 -0700 (PDT) In-Reply-To: <20070320154136.732272482@127.0.0.1> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> <20070320154136.732272482@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <903ECA9A-1669-4651-B714-27E6286D159E@cs.berkeley.edu> Cc: Scott Burleigh , dtn interest , Susan Content-Transfer-Encoding: 7bit From: Michael Demmer Subject: Re: Re(8): [dtn-interest] questions re bundle dictionary and flags X-Applemailsentby: demmer Date: Tue, 20 Mar 2007 10:18:33 -0700 To: Peter Lovell X-Mailer: Apple Mail (2.752.3) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: > Jon's situation is an interesting one and he's correct that it will > happen frequently. > > Much of the difficulty comes from the fact that EID references (the > pair > of 16-bit offsets) are present in many blocks. An alternative approach > would be to have these references in a table at the start of the > dictionary. So the dictionary would be a table followed by the EID > data > strings. The various places which presently have an "EID reference" > would instead have a "dictionary index", a small integer specifying an > entry in the table. > > This has an extra level of lookup (small additional overhead) but has > the big advantage that the internal layout of the dictionary data is > completely opaque. Thinking about this more, it occurs to me that we could achieve the benefits of Peter's proposal without requiring the index and extra layer of indirection at the start of the dictionary. Suppose we change dictionary references in all blocks to indices instead of offsets, as Peter suggested. A BPA can easily calculate the mapping of a dictionary index to the correct offset in the dictionary byte array by scanning the contents of the dictionary when it arrives, and keeping track of the locations of all the NULL terminators. That way even if the custodian (or other such fields) change from hop to hop, the index of the particular dictionary entries may not need to change, and thus blocks need not depend on them. We still would have the prior issue of determining when a BPA is allowed to remove entries from a dictionary for compression purposes, as mentioned earlier in this thread. -mike Received: from smtp.ietf68.org (egon.ietf68.org [130.129.5.7]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2KG50Y18582 for ; Tue, 20 Mar 2007 08:05:00 -0800 Received: from [10.0.0.254] (dhcp-4009.ietf68.org [130.129.64.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ietf68.org (Postfix) with ESMTP id C9F9C5005F; Tue, 20 Mar 2007 17:04:58 +0100 (CET) Message-ID: <46000680.5020105@cs.tcd.ie> Date: Tue, 20 Mar 2007 16:06:24 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Scott Burleigh CC: dtn interest Subject: Re: [dtn-interest] questions re bundle dictionary and flags References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <45FF1D3F.5090100@jpl.nasa.gov> <20070320020710.2058155815@127.0.0.1> <4600034A.1000801@jpl.nasa.gov> In-Reply-To: <4600034A.1000801@jpl.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Scott Burleigh wrote: > What I haven't yet thought much about is how this would interact with > security. CBHE compression would nominally want to be applied after the > bundle security blocks are created, so signatures and such would have > been generated from the uncompressed form of the bundle with all EIDs in > uncompressed form (that is, textual URIs in the dictionary), so we need > to be able to decompress/regenerate the bundle into that exact form in > order for bundle security to work. Which might mean that we need some > sort of a convention for dictionary structure in order to get CBHE and > BSP to coexist peacefully. Yes. We do need that. I think you could require (in the CBHE spec) that implementations have a way to map from compressed EIDs back - but that can be local, at least for the cases you want, right? I don't know if there're any cases of using CBHE where the verifier has to be able to check a signature on a bundle that involves a random EID, but if there are then CBHE has to define a probably optional compressed dictionary. > > Alternatively, maybe we want BSP to be applied *after* the primary block > is CBHE-compressed. But that seems at odds with doing CBHE compression > in the convergence layer, which nominally operates only on fully-formed > bundles. A puzzle. Yes. Signing will be common at the source, before the CBHE CL is hit. S. Received: from nmta2.jpl.nasa.gov (nmta2.jpl.nasa.gov [137.78.160.215]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2KFqoY18472 for ; Tue, 20 Mar 2007 07:52:50 -0800 Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by nmta2.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2KFqii9017647 for ; Tue, 20 Mar 2007 08:52:45 -0700 Received: from [127.0.0.1] (dhcp-79-22-247.jpl.nasa.gov [137.79.22.247]) by xmta2.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2KFqhGI021928 for ; Tue, 20 Mar 2007 08:52:44 -0700 Message-ID: <4600034A.1000801@jpl.nasa.gov> Date: Tue, 20 Mar 2007 08:52:42 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] questions re bundle dictionary and flags References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <45FF1D3F.5090100@jpl.nasa.gov> <20070320020710.2058155815@127.0.0.1> In-Reply-To: <20070320020710.2058155815@127.0.0.1> Content-Type: multipart/alternative; boundary="------------050202090502080509020608" X-Source-IP: dhcp-79-22-247.jpl.nasa.gov [137.79.22.247] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. --------------050202090502080509020608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Lovell wrote: > On Mon, Mar 19, 2007, Scott Burleigh wrote: > > >> Peter Lovell wrote: >> >>> On Mon, Mar 19, 2007, Michael Demmer wrote: >>> >>> >>>>> if I understand correctly, you're saying that the dictionary is >>>>> completely rebuilt on each hop [in the reference implementation]? >>>>> >>>>> >>>> Yes. >>>> >>>> Thinking a bit more carefully about things, the reference >>>> implementation doesn't actually discard the arriving dictionary since >>>> it's preserved along with all other arriving blocks. >>>> >>>> However the dictionary that's used when a bundle is transmitted is >>>> rebuilt each time in PrimaryBlockProcessor::generate(). >>>> >>>> >>> Yes - the latter piece is the significant part. >>> >>> What it means is that security processing, if it is to use the >>> dictionary, would have to process EIDs into the dictionary at every hop. >>> That's not what the current code does, but mainly because I have been >>> focussed on steps in order ... >>> 1. make it work >>> 2. make it fast [and otherwise better] >>> >>> I expect that the size saving [for security to use the dictionary] would >>> be worthwhile. This is just a gut feel, since we don't have actual >>> implementations to measure yet. But the case of gateway-to-gateway would >>> probably have several instances of the same EID string in various >>> security blocks. >>> >>> So, while the savings are presently unknown, I don't want to preclude >>> the possibility, without good reason. >>> >>> >> Peter, on a slightly different topic: have you given any thought to how >> the security protocol blocks could get CBHE-compressed? I think I'm >> going to need to use the protocol in space applications, but I would >> expect to have a hard time selling mission managers on it if it requires >> the transmission of standard URI-format EIDs. >> >> One nice thing about using EID references (dictionary offsets) instead >> of block-private URIs in the BSP blocks is that the same CBHE >> compression techniques would apply as in the primary block: we'd just >> encode a CBHE-style EID's element number into the scheme offset SDNV and >> its service number into the SSP offset SDNV. >> >> Scott >> > Hi Scott, > > yes - I have given some thought, although I must confess that it's not > as much as I would have liked. > > Your comments some time ago (I forget exactly when) had alerted me to > the size-sensitivity issues relating to security protocol. I certainly > want to make sure that the security spec, presently in revision, will > support CBHE references. As it is right now, the spec presumes direct > inclusion of EIDs in the various security blocks [not good]. Do you > perhaps have a description which would fit the security spec? If not, > perhaps we can talk about it tomorrow? My thought is that it's not > mandatory, as other users want to do other things, but that it should be > (i) easy and (ii) robust. > My first thought it that it wouldn't amount to much more than what I wrote above: wherever an EID reference (a pair of dictionary offsets in SDNV form) appears in a bundle protocol block, we would instead insert the element number and service number as parsed out of the SSP of the referenced EID. As with primary-block CBHE compression, this would only be possible when all EIDs referenced anywhere in the bundle are in CBHE format (:.) and all are for the same scheme. It's a special case of DTN deployment, but from the Interplanetary Internet point of view it's an important special case. What I haven't yet thought much about is how this would interact with security. CBHE compression would nominally want to be applied after the bundle security blocks are created, so signatures and such would have been generated from the uncompressed form of the bundle with all EIDs in uncompressed form (that is, textual URIs in the dictionary), so we need to be able to decompress/regenerate the bundle into that exact form in order for bundle security to work. Which might mean that we need some sort of a convention for dictionary structure in order to get CBHE and BSP to coexist peacefully. Alternatively, maybe we want BSP to be applied *after* the primary block is CBHE-compressed. But that seems at odds with doing CBHE compression in the convergence layer, which nominally operates only on fully-formed bundles. A puzzle. Scott --------------050202090502080509020608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Lovell wrote: 
On Mon, Mar 19, 2007, Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> wrote:

  
Peter Lovell wrote:
    
On Mon, Mar 19, 2007, Michael Demmer <demmer@cs.berkeley.edu> wrote:
  
      
if I understand correctly, you're saying that the dictionary is
completely rebuilt on each hop [in the reference implementation]?
      
          
Yes.

Thinking a bit more carefully about things, the reference  
implementation doesn't actually discard the arriving dictionary since  
it's preserved along with all other arriving blocks.

However the dictionary that's used when a bundle is transmitted is  
rebuilt each time in PrimaryBlockProcessor::generate().
    
        
Yes - the latter piece is the significant part.

What it means is that security processing, if it is to use the
dictionary, would have to process EIDs into the dictionary at every hop.
That's not what the current code does, but mainly because I have been
focussed on steps in order ...
1. make it work
2. make it fast [and otherwise better]

I expect that the size saving [for security to use the dictionary] would
be worthwhile. This is just a gut feel, since we don't have actual
implementations to measure yet. But the case of gateway-to-gateway would
probably have several instances of the same EID string in various
security blocks.

So, while the savings are presently unknown, I don't want to preclude
the possibility, without good reason.
  
      
Peter, on a slightly different topic: have you given any thought to how 
the security protocol blocks could get CBHE-compressed?  I think I'm 
going to need to use the protocol in space applications, but I would 
expect to have a hard time selling mission managers on it if it requires 
the transmission of standard URI-format EIDs.

One nice thing about using EID references (dictionary offsets) instead 
of block-private URIs in the BSP blocks is that the same CBHE 
compression techniques would apply as in the primary block: we'd just 
encode a CBHE-style EID's element number into the scheme offset SDNV and 
its service number into the SSP offset SDNV.

Scott
    
Hi Scott,

yes - I have given some thought, although I must confess that it's not
as much as I would have liked.

Your comments some time ago (I forget exactly when) had alerted me to
the size-sensitivity issues relating to security protocol. I certainly
want to make sure that the security spec, presently in revision, will
support CBHE references. As it is right now, the spec presumes direct
inclusion of EIDs in the various security blocks [not good]. Do you
perhaps have a description which would fit the security spec? If not,
perhaps we can talk about it tomorrow? My thought is that it's not
mandatory, as other users want to do other things, but that it should be
(i) easy and (ii) robust.
My first thought it that it wouldn't amount to much more than what I wrote above: wherever an EID reference (a pair of dictionary offsets in SDNV form) appears in a bundle protocol block, we would instead insert the element number and service number as parsed out of the SSP of the referenced EID.

As with primary-block CBHE compression, this would only be possible when all EIDs referenced anywhere in the bundle are in CBHE format (<scheme_name>:<element_number>.<service_number>) and all are for the same scheme.  It's a special case of DTN deployment, but from the Interplanetary Internet point of view it's an important special case.

What I haven't yet thought much about is how this would interact with security.  CBHE compression would nominally want to be applied after the bundle security blocks are created, so signatures and such would have been generated from the uncompressed form of the bundle with all EIDs in uncompressed form (that is, textual URIs in the dictionary), so we need to be able to decompress/regenerate the bundle into that exact form in order for bundle security to work.  Which might mean that we need some sort of a convention for dictionary structure in order to get CBHE and BSP to coexist peacefully.

Alternatively, maybe we want BSP to be applied *after* the primary block is CBHE-compressed.  But that seems at odds with doing CBHE compression in the convergence layer, which nominally operates only on fully-formed bundles.  A puzzle.

Scott
--------------050202090502080509020608-- Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2KFfjY18365 for ; Tue, 20 Mar 2007 07:41:45 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2KFfcrO015006; Tue, 20 Mar 2007 10:41:38 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2KFfbEW007246; Tue, 20 Mar 2007 10:41:38 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 11:41:36 -0400 From: "Peter Lovell" To: "Michael Demmer" Cc: "Scott Burleigh" , "dtn interest" , Susan Subject: Re(8): [dtn-interest] questions re bundle dictionary and flags Date: Tue, 20 Mar 2007 11:41:36 -0400 Message-Id: <20070320154136.732272482@127.0.0.1> In-Reply-To: <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2007 15:41:37.0170 (UTC) FILETIME=[3ED87F20:01C76B06] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 20 Mar 2007 10:41:40 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, Mar 19, 2007, Michael Demmer wrote: >> On Mon, Mar 19, 2007, Michael Demmer wrote: >> >>>> if I understand correctly, you're saying that the dictionary is >>>> completely rebuilt on each hop [in the reference implementation]? >>> >>> Yes. >>> >>> Thinking a bit more carefully about things, the reference >>> implementation doesn't actually discard the arriving dictionary since >>> it's preserved along with all other arriving blocks. >>> >>> However the dictionary that's used when a bundle is transmitted is >>> rebuilt each time in PrimaryBlockProcessor::generate(). >> >> >> Yes - the latter piece is the significant part. >> >> What it means is that security processing, if it is to use the >> dictionary, would have to process EIDs into the dictionary at every >> hop. >> That's not what the current code does, but mainly because I have been >> focussed on steps in order ... >> 1. make it work >> 2. make it fast [and otherwise better] >> >> I expect that the size saving [for security to use the dictionary] >> would >> be worthwhile. This is just a gut feel, since we don't have actual >> implementations to measure yet. But the case of gateway-to-gateway >> would >> probably have several instances of the same EID string in various >> security blocks. >> >> So, while the savings are presently unknown, I don't want to preclude >> the possibility, without good reason. > >I agree -- it would be good to make the reference implementation >amenable to allowing extension blocks (security-related and others) >to easily and efficiently use the dictionary. > >As I see it, this subsystem should allow clients to add EIDs to a >dictionary, look up the offsets for EID elements, remove references >that aren't needed (such as old custodians), and optionally pin EID >elements into certain locations. This last behavior is not currently >supported but would be needed to handle your requirements, i.e. that >the EIDs don't have to be re-processed at each hop. > >Let's discuss a more detailed design for this off-list. > >-mike > Jon's situation is an interesting one and he's correct that it will happen frequently. Much of the difficulty comes from the fact that EID references (the pair of 16-bit offsets) are present in many blocks. An alternative approach would be to have these references in a table at the start of the dictionary. So the dictionary would be a table followed by the EID data strings. The various places which presently have an "EID reference" would instead have a "dictionary index", a small integer specifying an entry in the table. This has an extra level of lookup (small additional overhead) but has the big advantage that the internal layout of the dictionary data is completely opaque. Cheers.....Peter Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2K27FY12921 for ; Mon, 19 Mar 2007 18:07:15 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2K27DFx018695; Mon, 19 Mar 2007 21:07:13 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2K27Csb017604; Mon, 19 Mar 2007 21:07:12 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 22:07:12 -0400 From: "Peter Lovell" To: "Scott Burleigh" , "dtn interest" Subject: Re(2): [dtn-interest] questions re bundle dictionary and flags Date: Mon, 19 Mar 2007 22:07:10 -0400 Message-Id: <20070320020710.2058155815@127.0.0.1> In-Reply-To: <45FF1D3F.5090100@jpl.nasa.gov> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> <45FF1D3F.5090100@jpl.nasa.gov> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2007 02:07:12.0557 (UTC) FILETIME=[794445D0:01C76A94] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 19 Mar 2007 21:07:13 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, Mar 19, 2007, Scott Burleigh wrote: >Peter Lovell wrote: >> On Mon, Mar 19, 2007, Michael Demmer wrote: >> >>>> if I understand correctly, you're saying that the dictionary is >>>> completely rebuilt on each hop [in the reference implementation]? >>>> >>> Yes. >>> >>> Thinking a bit more carefully about things, the reference >>> implementation doesn't actually discard the arriving dictionary since >>> it's preserved along with all other arriving blocks. >>> >>> However the dictionary that's used when a bundle is transmitted is >>> rebuilt each time in PrimaryBlockProcessor::generate(). >>> >> Yes - the latter piece is the significant part. >> >> What it means is that security processing, if it is to use the >> dictionary, would have to process EIDs into the dictionary at every hop. >> That's not what the current code does, but mainly because I have been >> focussed on steps in order ... >> 1. make it work >> 2. make it fast [and otherwise better] >> >> I expect that the size saving [for security to use the dictionary] would >> be worthwhile. This is just a gut feel, since we don't have actual >> implementations to measure yet. But the case of gateway-to-gateway would >> probably have several instances of the same EID string in various >> security blocks. >> >> So, while the savings are presently unknown, I don't want to preclude >> the possibility, without good reason. >> >Peter, on a slightly different topic: have you given any thought to how >the security protocol blocks could get CBHE-compressed? I think I'm >going to need to use the protocol in space applications, but I would >expect to have a hard time selling mission managers on it if it requires >the transmission of standard URI-format EIDs. > >One nice thing about using EID references (dictionary offsets) instead >of block-private URIs in the BSP blocks is that the same CBHE >compression techniques would apply as in the primary block: we'd just >encode a CBHE-style EID's element number into the scheme offset SDNV and >its service number into the SSP offset SDNV. > >Scott Hi Scott, yes - I have given some thought, although I must confess that it's not as much as I would have liked. Your comments some time ago (I forget exactly when) had alerted me to the size-sensitivity issues relating to security protocol. I certainly want to make sure that the security spec, presently in revision, will support CBHE references. As it is right now, the spec presumes direct inclusion of EIDs in the various security blocks [not good]. Do you perhaps have a description which would fit the security spec? If not, perhaps we can talk about it tomorrow? My thought is that it's not mandatory, as other users want to do other things, but that it should be (i) easy and (ii) robust. Cheers.....Peter Received: from nmta3.jpl.nasa.gov (nmta3.jpl.nasa.gov [137.78.160.108]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JNVQY11930 for ; Mon, 19 Mar 2007 15:31:26 -0800 Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta3.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2JNVLkJ028250 for ; Mon, 19 Mar 2007 16:31:21 -0700 Received: from [127.0.0.1] (dhcp-79-22-247.jpl.nasa.gov [137.79.22.247]) by xmta3.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2JNVBm6031263 for ; Mon, 19 Mar 2007 16:31:21 -0700 Message-ID: <45FF1D3F.5090100@jpl.nasa.gov> Date: Mon, 19 Mar 2007 16:31:11 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] questions re bundle dictionary and flags References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> In-Reply-To: <20070319214106.2060980645@127.0.0.1> Content-Type: multipart/alternative; boundary="------------090201070605040003020206" X-Source-IP: dhcp-79-22-247.jpl.nasa.gov [137.79.22.247] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. --------------090201070605040003020206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Lovell wrote: > On Mon, Mar 19, 2007, Michael Demmer wrote: > >>> if I understand correctly, you're saying that the dictionary is >>> completely rebuilt on each hop [in the reference implementation]? >>> >> Yes. >> >> Thinking a bit more carefully about things, the reference >> implementation doesn't actually discard the arriving dictionary since >> it's preserved along with all other arriving blocks. >> >> However the dictionary that's used when a bundle is transmitted is >> rebuilt each time in PrimaryBlockProcessor::generate(). >> > Yes - the latter piece is the significant part. > > What it means is that security processing, if it is to use the > dictionary, would have to process EIDs into the dictionary at every hop. > That's not what the current code does, but mainly because I have been > focussed on steps in order ... > 1. make it work > 2. make it fast [and otherwise better] > > I expect that the size saving [for security to use the dictionary] would > be worthwhile. This is just a gut feel, since we don't have actual > implementations to measure yet. But the case of gateway-to-gateway would > probably have several instances of the same EID string in various > security blocks. > > So, while the savings are presently unknown, I don't want to preclude > the possibility, without good reason. > Peter, on a slightly different topic: have you given any thought to how the security protocol blocks could get CBHE-compressed? I think I'm going to need to use the protocol in space applications, but I would expect to have a hard time selling mission managers on it if it requires the transmission of standard URI-format EIDs. One nice thing about using EID references (dictionary offsets) instead of block-private URIs in the BSP blocks is that the same CBHE compression techniques would apply as in the primary block: we'd just encode a CBHE-style EID's element number into the scheme offset SDNV and its service number into the SSP offset SDNV. Scott --------------090201070605040003020206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Lovell wrote: 
On Mon, Mar 19, 2007, Michael Demmer <demmer@cs.berkeley.edu> wrote:
  
if I understand correctly, you're saying that the dictionary is
completely rebuilt on each hop [in the reference implementation]?
      
Yes.

Thinking a bit more carefully about things, the reference  
implementation doesn't actually discard the arriving dictionary since  
it's preserved along with all other arriving blocks.

However the dictionary that's used when a bundle is transmitted is  
rebuilt each time in PrimaryBlockProcessor::generate().
    
Yes - the latter piece is the significant part.

What it means is that security processing, if it is to use the
dictionary, would have to process EIDs into the dictionary at every hop.
That's not what the current code does, but mainly because I have been
focussed on steps in order ...
1. make it work
2. make it fast [and otherwise better]

I expect that the size saving [for security to use the dictionary] would
be worthwhile. This is just a gut feel, since we don't have actual
implementations to measure yet. But the case of gateway-to-gateway would
probably have several instances of the same EID string in various
security blocks.

So, while the savings are presently unknown, I don't want to preclude
the possibility, without good reason.
Peter, on a slightly different topic: have you given any thought to how the security protocol blocks could get CBHE-compressed?  I think I'm going to need to use the protocol in space applications, but I would expect to have a hard time selling mission managers on it if it requires the transmission of standard URI-format EIDs.

One nice thing about using EID references (dictionary offsets) instead of block-private URIs in the BSP blocks is that the same CBHE compression techniques would apply as in the primary block: we'd just encode a CBHE-style EID's element number into the scheme offset SDNV and its service number into the SSP offset SDNV.

Scott
--------------090201070605040003020206-- Received: from ford.damogran.org (ford.damogran.org [216.127.74.27]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JNTFY11905 for ; Mon, 19 Mar 2007 15:29:15 -0800 Received: from [192.168.1.190] (h-74-0-64-138.atlngahp.covad.net [74.0.64.138]) by ford.damogran.org (Postfix) with ESMTP id C71A94140F3; Mon, 19 Mar 2007 18:29:13 -0500 (CDT) In-Reply-To: References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8753ED7C-2D0D-4625-86B2-C8373C0470A9@damogran.org> Cc: dtn interest Content-Transfer-Encoding: 7bit From: Jon Olson Subject: Re: Re(2): [dtn-interest] questions re bundle dictionary and flags Date: Mon, 19 Mar 2007 19:29:10 -0400 To: Michael Demmer X-Mailer: Apple Mail (2.752.3) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Mar 19, 2007, at 4:32 PM, Michael Demmer wrote: > > On Mar 19, 2007, at 12:22 PM, Peter Lovell wrote: > >> Thanks, Susan and Scott, that explains it fairly well. It did seem >> quite >> a puzzle. >> >>>> I wonder if we could instead >>>> stipulate that if a node doesn't understand one or more blocks of a >>>> bundle that are to be forwarded with the bundle, then the node >>>> must not >>>> revise the dictionary. I can't remember the discussion >>>> surrounding this >>>> text enough to recall whether we considered this possibility >>>> before. >>> Yes, that's a reasonable alternative approach. I don't think we >>> discussed it, but I can't think of any reason it wouldn't work. >> >> That does seem to be a good solution. To me it says, "You can >> compress >> the bundle but you can't break it" >> >> It has the advantage that extension processors can use the dictionary >> (very good for space-efficiency for EID strings) without the >> threat that >> their blocks could be silently deleted at any node (bad). > > I'd be ok with this change. > > I should point out that it would mean that an implementation can no > longer handle the dictionary by parsing it into separate > EndpointIDs on arrival, throwing away the dictionary text, and then > regenerating the dictionary when the bundle is forwarded. Not > coincidentally, this is what the current DTN2 reference > implementation does. > > -mike Our implementation preserves the dictionary unless it needs to make any changes to it (in which case we rebuild it)[0]. The most prominent scenario in which we need to revise the dictionary is when custody transfer is turned on. This also brings me to the biggest problem I see with this approach. If a new node becomes custodian of a bundle and they have a longer EID than the previous custodian then they either need to resize the existing custodian field (shifting everything beyond it) or leave the current one as is (or replace it with NULs or other some suitable marker) and put the new custodian at the end of the dictionary (thus not breaking any other offsets). Even the latter solution breaks if an extension block references the current custodian. Another option that I think is worth mentioning (although it would require potentially substantial changes and is therefore not necessarily practical at this stage) would be to modify the extension block flags. We could add a flag that indicates that this EB contains references to EIDs in the dictionary. If this bit is present, immediately following the extension block header is an SDNV indicating the number of referenced EIDs (which we'll call n here). Following this SDNV would be n additional SDNVs serving as indices into the dictionary. This would allow nodes to reconstruct the dictionary such that all extension blocks references to it would remain valid across nodes[1]. This brings me to another thought. We may want to add a flag to extension blocks that indicates that an upstream node did not process the block. This could be useful in the case of, for example, multipoint delivery related extension blocks. If nodes in the path do not understand the delivery paradigm in question they may still be able to route it to a node that does, and it may be useful to that node to know that somewhere in path this extension block was ignored (possibly at the previous hop, possibly several hops earlier). Of course any node that could successfully handle the block could clear this flag before forwarding it on. I'm not sure if this actually has significant utility, but I can imagine scenarios in which it might be helpful. Just my thoughts. -- Jon [0]: At least, that's the intended behavior of our implementation. At present I think we may regenerate it every time to narrow the scope on some dictionary corruption bugs we were experiencing. [1]: Unless of course proper processing of the block would result in a change to one of the referenced EIDs in the dictionary, in which case we would be left with valid references to potentially stale data. I'm not sure that's better. Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JM1xY11345 for ; Mon, 19 Mar 2007 14:01:59 -0800 Received: from [128.32.131.196] (dhcp-131-196.EECS.Berkeley.EDU [128.32.131.196]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.0/8.13.5) with ESMTP id l2JM1vAo004196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Mar 2007 15:01:58 -0700 (PDT) In-Reply-To: <20070319214106.2060980645@127.0.0.1> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> <20070319214106.2060980645@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8380660B-EE9D-4B78-B663-8C7681801709@cs.berkeley.edu> Cc: Scott Burleigh , dtn interest , Susan Content-Transfer-Encoding: 7bit From: Michael Demmer Subject: Re: Re(6): [dtn-interest] questions re bundle dictionary and flags X-Applemailsentby: demmer Date: Mon, 19 Mar 2007 15:01:58 -0700 To: Peter Lovell X-Mailer: Apple Mail (2.752.3) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: > On Mon, Mar 19, 2007, Michael Demmer wrote: > >>> if I understand correctly, you're saying that the dictionary is >>> completely rebuilt on each hop [in the reference implementation]? >> >> Yes. >> >> Thinking a bit more carefully about things, the reference >> implementation doesn't actually discard the arriving dictionary since >> it's preserved along with all other arriving blocks. >> >> However the dictionary that's used when a bundle is transmitted is >> rebuilt each time in PrimaryBlockProcessor::generate(). > > > Yes - the latter piece is the significant part. > > What it means is that security processing, if it is to use the > dictionary, would have to process EIDs into the dictionary at every > hop. > That's not what the current code does, but mainly because I have been > focussed on steps in order ... > 1. make it work > 2. make it fast [and otherwise better] > > I expect that the size saving [for security to use the dictionary] > would > be worthwhile. This is just a gut feel, since we don't have actual > implementations to measure yet. But the case of gateway-to-gateway > would > probably have several instances of the same EID string in various > security blocks. > > So, while the savings are presently unknown, I don't want to preclude > the possibility, without good reason. I agree -- it would be good to make the reference implementation amenable to allowing extension blocks (security-related and others) to easily and efficiently use the dictionary. As I see it, this subsystem should allow clients to add EIDs to a dictionary, look up the offsets for EID elements, remove references that aren't needed (such as old custodians), and optionally pin EID elements into certain locations. This last behavior is not currently supported but would be needed to handle your requirements, i.e. that the EIDs don't have to be re-processed at each hop. Let's discuss a more detailed design for this off-list. -mike Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JLgPY11196 for ; Mon, 19 Mar 2007 13:42:25 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2JLgKvh007616; Mon, 19 Mar 2007 16:42:20 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2JLgKuV010268; Mon, 19 Mar 2007 16:42:20 -0500 Received: from [192.168.0.4] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:42:20 -0400 From: "Peter Lovell" To: "Michael Demmer" Cc: "Scott Burleigh" , "dtn interest" , Susan Subject: Re(6): [dtn-interest] questions re bundle dictionary and flags Date: Mon, 19 Mar 2007 17:41:06 -0400 Message-Id: <20070319214106.2060980645@127.0.0.1> In-Reply-To: References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (intel) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 21:42:20.0179 (UTC) FILETIME=[78ABD630:01C76A6F] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 19 Mar 2007 16:42:20 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, Mar 19, 2007, Michael Demmer wrote: >> if I understand correctly, you're saying that the dictionary is >> completely rebuilt on each hop [in the reference implementation]? > >Yes. > >Thinking a bit more carefully about things, the reference >implementation doesn't actually discard the arriving dictionary since >it's preserved along with all other arriving blocks. > >However the dictionary that's used when a bundle is transmitted is >rebuilt each time in PrimaryBlockProcessor::generate(). Yes - the latter piece is the significant part. What it means is that security processing, if it is to use the dictionary, would have to process EIDs into the dictionary at every hop. That's not what the current code does, but mainly because I have been focussed on steps in order ... 1. make it work 2. make it fast [and otherwise better] I expect that the size saving [for security to use the dictionary] would be worthwhile. This is just a gut feel, since we don't have actual implementations to measure yet. But the case of gateway-to-gateway would probably have several instances of the same EID string in various security blocks. So, while the savings are presently unknown, I don't want to preclude the possibility, without good reason. Cheers.....Peter Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JL9LY10980 for ; Mon, 19 Mar 2007 13:09:21 -0800 Received: from [128.32.131.196] (dhcp-131-196.EECS.Berkeley.EDU [128.32.131.196]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.0/8.13.5) with ESMTP id l2JL9JZZ002914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Mar 2007 14:09:20 -0700 (PDT) In-Reply-To: <20070319210408.1971687890@127.0.0.1> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> <20070319210408.1971687890@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Scott Burleigh , dtn interest , Susan Content-Transfer-Encoding: 7bit From: Michael Demmer Subject: Re: Re(4): [dtn-interest] questions re bundle dictionary and flags X-Applemailsentby: demmer Date: Mon, 19 Mar 2007 14:09:20 -0700 To: Peter Lovell X-Mailer: Apple Mail (2.752.3) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: > if I understand correctly, you're saying that the dictionary is > completely rebuilt on each hop [in the reference implementation]? Yes. Thinking a bit more carefully about things, the reference implementation doesn't actually discard the arriving dictionary since it's preserved along with all other arriving blocks. However the dictionary that's used when a bundle is transmitted is rebuilt each time in PrimaryBlockProcessor::generate(). -mike Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JL4KY10936 for ; Mon, 19 Mar 2007 13:04:20 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2JL4BiA005546; Mon, 19 Mar 2007 16:04:11 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2JL4AR9008607; Mon, 19 Mar 2007 16:04:10 -0500 Received: from [192.168.0.4] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:04:10 -0400 From: "Peter Lovell" To: "Michael Demmer" Cc: "Scott Burleigh" , "dtn interest" , Susan Subject: Re(4): [dtn-interest] questions re bundle dictionary and flags Date: Mon, 19 Mar 2007 17:04:08 -0400 Message-Id: <20070319210408.1971687890@127.0.0.1> In-Reply-To: References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (intel) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 21:04:10.0460 (UTC) FILETIME=[23E471C0:01C76A6A] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 19 Mar 2007 16:04:11 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, Mar 19, 2007, Michael Demmer wrote: >handle the dictionary by parsing it into separate EndpointIDs >on arrival, throwing away the dictionary text, and then regenerating >the dictionary when the bundle is forwarded. Not coincidentally, this >is what the current DTN2 reference implementation does. Hi Mike, if I understand correctly, you're saying that the dictionary is completely rebuilt on each hop [in the reference implementation]? Thanks.....Peter Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JKWkY10676 for ; Mon, 19 Mar 2007 12:32:46 -0800 Received: from [128.32.131.196] (dhcp-131-196.EECS.Berkeley.EDU [128.32.131.196]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.0/8.13.5) with ESMTP id l2JKWf4I001965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Mar 2007 13:32:42 -0700 (PDT) In-Reply-To: <20070319192238.1931988502@127.0.0.1> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> <20070319192238.1931988502@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Scott Burleigh , dtn interest , Susan Content-Transfer-Encoding: 7bit From: Michael Demmer Subject: Re: Re(2): [dtn-interest] questions re bundle dictionary and flags X-Applemailsentby: demmer Date: Mon, 19 Mar 2007 13:32:42 -0700 To: Peter Lovell X-Mailer: Apple Mail (2.752.3) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Mar 19, 2007, at 12:22 PM, Peter Lovell wrote: > Thanks, Susan and Scott, that explains it fairly well. It did seem > quite > a puzzle. > >>> I wonder if we could instead >>> stipulate that if a node doesn't understand one or more blocks of a >>> bundle that are to be forwarded with the bundle, then the node >>> must not >>> revise the dictionary. I can't remember the discussion >>> surrounding this >>> text enough to recall whether we considered this possibility before. >> Yes, that's a reasonable alternative approach. I don't think we >> discussed it, but I can't think of any reason it wouldn't work. > > That does seem to be a good solution. To me it says, "You can compress > the bundle but you can't break it" > > It has the advantage that extension processors can use the dictionary > (very good for space-efficiency for EID strings) without the threat > that > their blocks could be silently deleted at any node (bad). I'd be ok with this change. I should point out that it would mean that an implementation can no longer handle the dictionary by parsing it into separate EndpointIDs on arrival, throwing away the dictionary text, and then regenerating the dictionary when the bundle is forwarded. Not coincidentally, this is what the current DTN2 reference implementation does. -mike Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JJMmY10251 for ; Mon, 19 Mar 2007 11:22:48 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2JJMgTH031171; Mon, 19 Mar 2007 14:22:42 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2JJMfmG002950; Mon, 19 Mar 2007 14:22:42 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 15:22:40 -0400 From: "Peter Lovell" To: "Scott Burleigh" , "dtn interest" , Susan Subject: Re(2): [dtn-interest] questions re bundle dictionary and flags Date: Mon, 19 Mar 2007 15:22:38 -0400 Message-Id: <20070319192238.1931988502@127.0.0.1> In-Reply-To: <45FEBDB5.7020207@jpl.nasa.gov> References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> <45FEBDB5.7020207@jpl.nasa.gov> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 19:22:41.0414 (UTC) FILETIME=[F689C260:01C76A5B] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 19 Mar 2007 14:22:45 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Thanks, Susan and Scott, that explains it fairly well. It did seem quite a puzzle. >> I wonder if we could instead >> stipulate that if a node doesn't understand one or more blocks of a >> bundle that are to be forwarded with the bundle, then the node must not >> revise the dictionary. I can't remember the discussion surrounding this >> text enough to recall whether we considered this possibility before. >Yes, that's a reasonable alternative approach. I don't think we >discussed it, but I can't think of any reason it wouldn't work. That does seem to be a good solution. To me it says, "You can compress the bundle but you can't break it" It has the advantage that extension processors can use the dictionary (very good for space-efficiency for EID strings) without the threat that their blocks could be silently deleted at any node (bad). Thanks.....Peter On Mon, Mar 19, 2007, Scott Burleigh wrote: >Symington, Susan F. wrote: >> Peter, >> >> I can't answer your question completely, but I'm going to respond >> anyway. >> >> I had thought that the reason for requiring one of these flags to be >> set was to ensure that the dictionary would be revised correctly when >> the bundle is forwarded, but now I'm not so sure. >> >I think that's more or less the reason. The spec (section 3.8) allows a >forwarding bundle protocol agent to remove from a bundle's dictionary >any strings for which there are no EID references, and when doing so the >agent is required to adjust EID references as necessary as the locations >of strings in the dictionary change due to the removal of other >strings. If the agent can't process an extension block, then it can't >know whether or not there are any EID references in it; this would make >it unable know when it's safe to compress unreferenced strings out of >the dictionary and also unable to adjust all EID references in the event >that some strings were removed. To resolve this conflict, we agreed >that an extension block could only contain EID references (pointers into >the dictionary) if bundle agents that couldn't process it were >authorized either to discard the block or to delete the bundle. >> In order for a node to be able to use the items in the dictionary, the >> node must be able to tell where each of the items begins and ends. The >> node tells where each item begins because the offset for that item's >> beginning is stored in some field in the bundle. The node tells where >> each item ends because each item is null-terminated. (Actually, I think >> the spec should probably be revised to say this explicitly; if it says >> it already for all items, I've missed it.) >In 3.6.1, on page 18 of the December 2006 draft, the description of the >Dictionary field says that the dictionary comprises null-terminated >scheme names and SSPs. >> If the offset value for a >> dictionary item happens to be stored in a field of an optional >> extension block and a node doesn't understand that extension block, >> then the node has no way of knowing that there is even a dictionary >> offset value in the extension block. In this case, if the node were to >> forward the bundle without deleting the extension block, the node would >> not be able to revise the dictionary by removing items that are not >> referenced by the bundle (because it cannot tell wheter or not the >> extension block it doesn't understand references a dictionary item). >> So, if our goal is to ensure that whenever a bundle is forwarded, its >> dictionary doesn't contain any items that are not referenced within the >> bundle, it makes sense to require that any extension block that >> references the dictionary have either the discard block or delete >> bundle if block can't be processed flag set. This way, if the bunde is >> forwarded, the forwarding node can be assured that none of the >> extension blocks that it doesn't understand references the dictionary, >> and it can therefore revise the dictionary correctly even though it >> doesn't understand some extension blocks that are still left in it. >> >> I had thought this was the reason, but what doesn't make sense to me is >> that the spec doesn't require each node to perform dictionary revision. >> It says that (section 3.8) "Any of the strings (scheme names and SSPS) >> in a bundle's dictionary to which no endpoint ID references in the >> bundle curently refer MAY be removed from the dictionary at the timet >> he bundle is forwarded...." >> >> It seems that if we are not requiring nodes to revise the dictionary by >> removing unreferenced items when the bundle is forarded, then we don't >> seem to need the requirement that if a block references the dictionary, >> it must have a discard/delete flag set. >It's not a question of whether or not the bundle protocol agent is >required to compress the dictionary, it's that we want to make sure that >the bundle doesn't get broken in the event that the agent chooses to >compress the dictionary. >> I wonder if we could instead >> stipulate that if a node doesn't understand one or more blocks of a >> bundle that are to be forwarded with the bundle, then the node must not >> revise the dictionary. I can't remember the discussion surrounding this >> text enough to recall whether we considered this possibility before. >Yes, that's a reasonable alternative approach. I don't think we >discussed it, but I can't think of any reason it wouldn't work. > >Scott >> So, there is an incomplete answer to your question. Hopefully it will >> job someone else's memory enough that they can chime in with something >> more definitive. >> >> Also, it is probably worth pointing out that there are no assumptions >> made regarding the order of the items in the dictionary. I understand >> the desire to be flexible and not impose unnecessary contraints, but >> this strikes me as something we may want to revisit. It doesn't seem to >> me that it would be overly constraining to require that the four >> offsets for the source and destination always be at the front of the >> dictionary. These strings never change, so if they were guaranteed to >> be at the beginning of the dictionary, then I think an extension block >> could reference them and still be forwarded by a node that revises the >> bundle even if the node doesn't understand the extension block that >> references them. If these strings were later in a dictionary and an >> extension block referenced one of them, and a node were to delete an >> item in the dictionary that preceded these strings, then the node would >> not be able to update the offset in the extension block accordingly >> because it doesn't understand the extension block. >> >> -susan >> ***************************************************************** >> Susan Symington >> The MITRE Corporation >> susan@mitre.org >> 703-983-7209 (voice) >> 703-983-7142 (fax) >> ****************************************************************** >> >> >>> -----Original Message----- >>> From: dtn-interest-admin@mailman.dtnrg.org >>> [mailto:dtn-interest-admin@mailman.dtnrg.org] On Behalf Of Peter Lovell >>> >>> Sent: Saturday, March 17, 2007 4:49 PM >>> To: dtn interest >>> Subject: [dtn-interest] questions re bundle dictionary and flags >>> >>> Hi all, >>> >>> while reviewing the update, an interesting question occurs to me. >>> >>> Section 3.7 "Extension blocks" contains the following ... >>> >>> Any extension block that contains citations of endpoint IDs that are >>> contained in the dictionary of the bundle's primary block >>> should have >>> the "Discard block if it can't be processed" flag set to 1 in the >>> block processing flags field of that extension block. >>> >>> Any extension block that has neither the "Discard block if it can't >>> be processed" flag nor the "Delete bundle if block can't be >>> processed" flag set to 1 in its block processing flags field >>> must not >>> contain any citations of endpoint IDs that are contained in the >>> dictionary of the bundle's primary block. >>> >>> Security blocks will typically, although not always, NOT have these >>> flags set. That is because intermediate forwarding nodes might not be >>> security-aware but we don't want the security blocks deleted. They're >>> not destined for the intermediate nodes so we don't care if those nodes >>> >>> can process them or not. >>> >>> But the way I read this says that, if the flags are not set, the >>> security blocks cannot have EID references in the dictionary. Not even >>> for the source and destination. >>> >>> I'd like to be able to use the size-compression benefit of the >>> dictionary within the security blocks, so I'm wondering about the >>> restriction. Will someone enlighten me why one or other of these flags >>> must be set in order to use EID references? >>> Received: from nmta2.jpl.nasa.gov (nmta2.jpl.nasa.gov [137.78.160.215]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JGhfY09287 for ; Mon, 19 Mar 2007 08:43:41 -0800 Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta2.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2JGhaqP031928 for ; Mon, 19 Mar 2007 09:43:36 -0700 Received: from [127.0.0.1] (dhcp-79-22-247.jpl.nasa.gov [137.79.22.247]) by xmta3.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2JGhYVI030004 for ; Mon, 19 Mar 2007 09:43:35 -0700 Message-ID: <45FEBDB5.7020207@jpl.nasa.gov> Date: Mon, 19 Mar 2007 09:43:33 -0700 From: Scott Burleigh User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn interest Subject: Re: [dtn-interest] questions re bundle dictionary and flags References: <20070317204848.869887362@127.0.0.1> <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> Content-Type: multipart/alternative; boundary="------------060701080905020200040803" X-Source-IP: dhcp-79-22-247.jpl.nasa.gov [137.79.22.247] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. --------------060701080905020200040803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Symington, Susan F. wrote: > Peter, > > I can't answer your question completely, but I'm going to respond > anyway. > > I had thought that the reason for requiring one of these flags to be > set was to ensure that the dictionary would be revised correctly when > the bundle is forwarded, but now I'm not so sure. > I think that's more or less the reason. The spec (section 3.8) allows a forwarding bundle protocol agent to remove from a bundle's dictionary any strings for which there are no EID references, and when doing so the agent is required to adjust EID references as necessary as the locations of strings in the dictionary change due to the removal of other strings. If the agent can't process an extension block, then it can't know whether or not there are any EID references in it; this would make it unable know when it's safe to compress unreferenced strings out of the dictionary and also unable to adjust all EID references in the event that some strings were removed. To resolve this conflict, we agreed that an extension block could only contain EID references (pointers into the dictionary) if bundle agents that couldn't process it were authorized either to discard the block or to delete the bundle. > In order for a node to be able to use the items in the dictionary, the > node must be able to tell where each of the items begins and ends. The > node tells where each item begins because the offset for that item's > beginning is stored in some field in the bundle. The node tells where > each item ends because each item is null-terminated. (Actually, I think > the spec should probably be revised to say this explicitly; if it says > it already for all items, I've missed it.) In 3.6.1, on page 18 of the December 2006 draft, the description of the Dictionary field says that the dictionary comprises null-terminated scheme names and SSPs. > If the offset value for a > dictionary item happens to be stored in a field of an optional > extension block and a node doesn't understand that extension block, > then the node has no way of knowing that there is even a dictionary > offset value in the extension block. In this case, if the node were to > forward the bundle without deleting the extension block, the node would > not be able to revise the dictionary by removing items that are not > referenced by the bundle (because it cannot tell wheter or not the > extension block it doesn't understand references a dictionary item). > So, if our goal is to ensure that whenever a bundle is forwarded, its > dictionary doesn't contain any items that are not referenced within the > bundle, it makes sense to require that any extension block that > references the dictionary have either the discard block or delete > bundle if block can't be processed flag set. This way, if the bunde is > forwarded, the forwarding node can be assured that none of the > extension blocks that it doesn't understand references the dictionary, > and it can therefore revise the dictionary correctly even though it > doesn't understand some extension blocks that are still left in it. > > I had thought this was the reason, but what doesn't make sense to me is > that the spec doesn't require each node to perform dictionary revision. > It says that (section 3.8) "Any of the strings (scheme names and SSPS) > in a bundle's dictionary to which no endpoint ID references in the > bundle curently refer MAY be removed from the dictionary at the timet > he bundle is forwarded...." > > It seems that if we are not requiring nodes to revise the dictionary by > removing unreferenced items when the bundle is forarded, then we don't > seem to need the requirement that if a block references the dictionary, > it must have a discard/delete flag set. It's not a question of whether or not the bundle protocol agent is required to compress the dictionary, it's that we want to make sure that the bundle doesn't get broken in the event that the agent chooses to compress the dictionary. > I wonder if we could instead > stipulate that if a node doesn't understand one or more blocks of a > bundle that are to be forwarded with the bundle, then the node must not > revise the dictionary. I can't remember the discussion surrounding this > text enough to recall whether we considered this possibility before. Yes, that's a reasonable alternative approach. I don't think we discussed it, but I can't think of any reason it wouldn't work. Scott > So, there is an incomplete answer to your question. Hopefully it will > job someone else's memory enough that they can chime in with something > more definitive. > > Also, it is probably worth pointing out that there are no assumptions > made regarding the order of the items in the dictionary. I understand > the desire to be flexible and not impose unnecessary contraints, but > this strikes me as something we may want to revisit. It doesn't seem to > me that it would be overly constraining to require that the four > offsets for the source and destination always be at the front of the > dictionary. These strings never change, so if they were guaranteed to > be at the beginning of the dictionary, then I think an extension block > could reference them and still be forwarded by a node that revises the > bundle even if the node doesn't understand the extension block that > references them. If these strings were later in a dictionary and an > extension block referenced one of them, and a node were to delete an > item in the dictionary that preceded these strings, then the node would > not be able to update the offset in the extension block accordingly > because it doesn't understand the extension block. > > -susan > ***************************************************************** > Susan Symington > The MITRE Corporation > susan@mitre.org > 703-983-7209 (voice) > 703-983-7142 (fax) > ****************************************************************** > > >> -----Original Message----- >> From: dtn-interest-admin@mailman.dtnrg.org >> [mailto:dtn-interest-admin@mailman.dtnrg.org] On Behalf Of Peter Lovell >> >> Sent: Saturday, March 17, 2007 4:49 PM >> To: dtn interest >> Subject: [dtn-interest] questions re bundle dictionary and flags >> >> Hi all, >> >> while reviewing the update, an interesting question occurs to me. >> >> Section 3.7 "Extension blocks" contains the following ... >> >> Any extension block that contains citations of endpoint IDs that are >> contained in the dictionary of the bundle's primary block >> should have >> the "Discard block if it can't be processed" flag set to 1 in the >> block processing flags field of that extension block. >> >> Any extension block that has neither the "Discard block if it can't >> be processed" flag nor the "Delete bundle if block can't be >> processed" flag set to 1 in its block processing flags field >> must not >> contain any citations of endpoint IDs that are contained in the >> dictionary of the bundle's primary block. >> >> Security blocks will typically, although not always, NOT have these >> flags set. That is because intermediate forwarding nodes might not be >> security-aware but we don't want the security blocks deleted. They're >> not destined for the intermediate nodes so we don't care if those nodes >> >> can process them or not. >> >> But the way I read this says that, if the flags are not set, the >> security blocks cannot have EID references in the dictionary. Not even >> for the source and destination. >> >> I'd like to be able to use the size-compression benefit of the >> dictionary within the security blocks, so I'm wondering about the >> restriction. Will someone enlighten me why one or other of these flags >> must be set in order to use EID references? >> --------------060701080905020200040803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Symington, Susan F. wrote: 
Peter,

I can't answer your question completely, but I'm going to respond
anyway.

I had thought that the reason for requiring one of these flags to be
set was to ensure that the dictionary would be revised correctly when
the bundle is forwarded, but now I'm not so sure.
I think that's more or less the reason.  The spec (section 3.8) allows a forwarding bundle protocol agent to remove from a bundle's dictionary any strings for which there are no EID references, and when doing so the agent is required to adjust EID references as necessary as the locations of strings in the dictionary change due to the removal of other strings.  If the agent can't process an extension block, then it can't know whether or not there are any EID references in it; this would make it unable know when it's safe to compress unreferenced strings out of the dictionary and also unable to adjust all EID references in the event that some strings were removed.  To resolve this conflict, we agreed that an extension block could only contain EID references (pointers into the dictionary) if bundle agents that couldn't process it were authorized either to discard the block or to delete the bundle.
In order for a node to be able to use the items in the dictionary, the
node must be able to tell where each of the items begins and ends. The
node tells where each item begins because the offset for that item's
beginning is stored in some field in the bundle. The node tells where
each item ends because each item is null-terminated. (Actually, I think
the spec should probably be revised to say this explicitly; if it says
it already for all items, I've missed it.)
In 3.6.1, on page 18 of the December 2006 draft, the description of the Dictionary field says that the dictionary comprises null-terminated scheme names and SSPs.
If the offset value for a
dictionary item happens to be stored in a field of an optional
extension block and a node doesn't understand that extension block,
then the node has no way of knowing that there is even a dictionary
offset value in the extension block. In this case, if the node were to
forward the bundle without deleting the extension block, the node would
not be able to revise the dictionary by removing items that are not
referenced by the bundle (because it cannot tell wheter or not the
extension block it doesn't understand references a dictionary item).
So, if our goal is to ensure that whenever a bundle is forwarded, its
dictionary doesn't contain any items that are not referenced within the
bundle, it makes sense to require that any extension block that
references the dictionary have either the discard block or delete
bundle if block can't be processed flag set. This way, if the bunde is
forwarded, the forwarding node can be assured that none of the
extension blocks that it doesn't understand references the dictionary,
and it can therefore revise the dictionary correctly even though it
doesn't understand some extension blocks that are still left in it.

I had thought this was the reason, but what doesn't make sense to me is
that the spec doesn't require each node to perform dictionary revision.
It says that (section 3.8) "Any of the strings (scheme names and SSPS)
in a bundle's dictionary to which no endpoint ID references in the
bundle curently refer MAY be removed from the dictionary at the timet
he bundle is forwarded...."

It seems that if we are not requiring nodes to revise the dictionary by
removing unreferenced items when the bundle is forarded, then we don't
seem to need the requirement that if a block references the dictionary,
it must have a discard/delete flag set.
It's not a question of whether or not the bundle protocol agent is required to compress the dictionary, it's that we want to make sure that the bundle doesn't get broken in the event that the agent chooses to compress the dictionary.
I wonder if we could instead
stipulate that if a node doesn't understand one or more blocks of a
bundle that are to be forwarded with the bundle, then the node must not
revise the dictionary. I can't remember the discussion surrounding this
text enough to recall whether we considered this possibility before.
Yes, that's a reasonable alternative approach.  I don't think we discussed it, but I can't think of any reason it wouldn't work.

Scott
So, there is an incomplete answer to your question. Hopefully it will
job someone else's memory enough that they can chime in with something
more definitive.

Also, it is probably worth pointing out that there are no assumptions
made regarding the order of the items in the dictionary. I understand
the desire to be flexible and not impose unnecessary contraints, but
this strikes me as something we may want to revisit. It doesn't seem to
me that it would be overly constraining to require that the four
offsets for the source and destination always be at the front of the
dictionary. These strings never change, so if they were guaranteed to
be at the beginning of the dictionary, then I think an extension block
could reference them and still be forwarded by a node that revises the
bundle even if the node doesn't understand the extension block that
references them. If these strings were later in a dictionary and an
extension block referenced one of them, and a node were to delete an
item in the dictionary that preceded these strings, then the node would
not be able to update the offset in the extension block accordingly
because it doesn't understand the extension block.

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
susan@mitre.org
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

  
-----Original Message-----
From: dtn-interest-admin@mailman.dtnrg.org 
[mailto:dtn-interest-admin@mailman.dtnrg.org] On Behalf Of Peter Lovell
    
Sent: Saturday, March 17, 2007 4:49 PM
To: dtn interest
Subject: [dtn-interest] questions re bundle dictionary and flags

Hi all, 

while reviewing the update, an interesting question occurs to me.

Section 3.7 "Extension blocks" contains the following ...
  
 Any extension block that contains citations of endpoint IDs that are
contained in the dictionary of the bundle's primary block 
should have 
 the "Discard block if it can't be processed" flag set to 1 in the 
 block processing flags field of that extension block. 

 Any extension block that has neither the "Discard block if it can't 
 be processed" flag nor the "Delete bundle if block can't be 
 processed" flag set to 1 in its block processing flags field 
must not 
 contain any citations of endpoint IDs that are contained in the 
 dictionary of the bundle's primary block. 

Security blocks will typically, although not always, NOT have these
flags set. That is because intermediate forwarding nodes might not be
security-aware but we don't want the security blocks deleted. They're
not destined for the intermediate nodes so we don't care if those nodes
    
can process them or not.

But the way I read this says that, if the flags are not set, the
security blocks cannot have EID references in the dictionary. Not even
for the source and destination.

I'd like to be able to use the size-compression benefit of the
dictionary within the security blocks, so I'm wondering about the
restriction. Will someone enlighten me why one or other of these flags
must be set in order to use EID references?
--------------060701080905020200040803-- Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2JFoUY08960 for ; Mon, 19 Mar 2007 07:50:30 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l2JFoToX001572 for ; Mon, 19 Mar 2007 11:50:29 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 5C42FBF00 for ; Mon, 19 Mar 2007 11:50:29 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l2JFoTCe001538; Mon, 19 Mar 2007 11:50:29 -0400 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 11:50:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dtn-interest] questions re bundle dictionary and flags Date: Mon, 19 Mar 2007 11:50:26 -0400 Message-ID: <8E507634779E22488719233DB3DF9FF0015E948C@IMCSRV4.MITRE.ORG> In-Reply-To: <20070317204848.869887362@127.0.0.1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] questions re bundle dictionary and flags Thread-Index: Acdo1edlP2ArJzBaQY+XavvnGJp8QABY8Kbw References: <20070317204848.869887362@127.0.0.1> From: "Symington, Susan F." To: "Peter Lovell" , "dtn interest" X-OriginalArrivalTime: 19 Mar 2007 15:50:28.0844 (UTC) FILETIME=[5155C2C0:01C76A3E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id l2JFoUY08960 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Peter, I can't answer your question completely, but I'm going to respond anyway. I had thought that the reason for requiring one of these flags to be set was to ensure that the dictionary would be revised correctly when the bundle is forwarded, but now I'm not so sure. In order for a node to be able to use the items in the dictionary, the node must be able to tell where each of the items begins and ends. The node tells where each item begins because the offset for that item's beginning is stored in some field in the bundle. The node tells where each item ends because each item is null-terminated. (Actually, I think the spec should probably be revised to say this explicitly; if it says it already for all items, I've missed it.) If the offset value for a dictionary item happens to be stored in a field of an optional extension block and a node doesn't understand that extension block, then the node has no way of knowing that there is even a dictionary offset value in the extension block. In this case, if the node were to forward the bundle without deleting the extension block, the node would not be able to revise the dictionary by removing items that are not referenced by the bundle (because it cannot tell wheter or not the extension block it doesn't understand references a dictionary item). So, if our goal is to ensure that whenever a bundle is forwarded, its dictionary doesn't contain any items that are not referenced within the bundle, it makes sense to require that any extension block that references the dictionary have either the discard block or delete bundle if block can't be processed flag set. This way, if the bunde is forwarded, the forwarding node can be assured that none of the extension blocks that it doesn't understand references the dictionary, and it can therefore revise the dictionary correctly even though it doesn't understand some extension blocks that are still left in it. I had thought this was the reason, but what doesn't make sense to me is that the spec doesn't require each node to perform dictionary revision. It says that (section 3.8) "Any of the strings (scheme names and SSPS) in a bundle's dictionary to which no endpoint ID references in the bundle curently refer MAY be removed from the dictionary at the timet he bundle is forwarded...." It seems that if we are not requiring nodes to revise the dictionary by removing unreferenced items when the bundle is forarded, then we don't seem to need the requirement that if a block references the dictionary, it must have a discard/delete flag set. I wonder if we could instead stipulate that if a node doesn't understand one or more blocks of a bundle that are to be forwarded with the bundle, then the node must not revise the dictionary. I can't remember the discussion surrounding this text enough to recall whether we considered this possibility before. So, there is an incomplete answer to your question. Hopefully it will job someone else's memory enough that they can chime in with something more definitive. Also, it is probably worth pointing out that there are no assumptions made regarding the order of the items in the dictionary. I understand the desire to be flexible and not impose unnecessary contraints, but this strikes me as something we may want to revisit. It doesn't seem to me that it would be overly constraining to require that the four offsets for the source and destination always be at the front of the dictionary. These strings never change, so if they were guaranteed to be at the beginning of the dictionary, then I think an extension block could reference them and still be forwarded by a node that revises the bundle even if the node doesn't understand the extension block that references them. If these strings were later in a dictionary and an extension block referenced one of them, and a node were to delete an item in the dictionary that preceded these strings, then the node would not be able to update the offset in the extension block accordingly because it doesn't understand the extension block. -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** >-----Original Message----- >From: dtn-interest-admin@mailman.dtnrg.org >[mailto:dtn-interest-admin@mailman.dtnrg.org] On Behalf Of Peter Lovell >Sent: Saturday, March 17, 2007 4:49 PM >To: dtn interest >Subject: [dtn-interest] questions re bundle dictionary and flags > >Hi all, > >while reviewing the update, an interesting question occurs to me. > >Section 3.7 "Extension blocks" contains the following ... > > Any extension block that contains citations of endpoint IDs that are > contained in the dictionary of the bundle's primary block >should have > the "Discard block if it can't be processed" flag set to 1 in the > block processing flags field of that extension block. > > Any extension block that has neither the "Discard block if it can't > be processed" flag nor the "Delete bundle if block can't be > processed" flag set to 1 in its block processing flags field >must not > contain any citations of endpoint IDs that are contained in the > dictionary of the bundle's primary block. > >Security blocks will typically, although not always, NOT have these >flags set. That is because intermediate forwarding nodes might not be >security-aware but we don't want the security blocks deleted. They're >not destined for the intermediate nodes so we don't care if those nodes >can process them or not. > >But the way I read this says that, if the flags are not set, the >security blocks cannot have EID references in the dictionary. Not even >for the source and destination. > >I'd like to be able to use the size-compression benefit of the >dictionary within the security blocks, so I'm wondering about the >restriction. Will someone enlighten me why one or other of these flags >must be set in order to use EID references? > >Thanks....Peter > >_______________________________________________ >dtn-interest mailing list >dtn-interest@mailman.dtnrg.org >http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > Received: from smtp.unilim.fr (mail.unilim.fr [164.81.1.45]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2IEIJY31846 for ; Sun, 18 Mar 2007 06:18:19 -0800 Received: from [192.168.0.2] ([84.5.72.27]) (authenticated bits=0) by smtp.unilim.fr (8.13.1/8.13.1) with ESMTP id l2IEIFWC014421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Mar 2007 15:18:16 +0100 Message-ID: <45FD4A26.40200@xlim.fr> Date: Sun, 18 Mar 2007 15:18:14 +0100 From: Damien Sauveron User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Univ-Limoges-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (smtp.unilim.fr [164.81.1.45]); Sun, 18 Mar 2007 15:18:16 +0100 (CET) X-Univ-Limoges-MailScanner-Information: Serveur Anti-virus Please contact the SCI, Univ. of Limoges, for more information X-Univ-Limoges-MailScanner: Found to be clean X-Univ-Limoges-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (cached, score=-101.789, requis 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_50 0.00, NO_RDNS2 0.01, SMTP_AUTH -100.00) X-Univ-Limoges-MailScanner-Envelope-From: damien.sauveron@xlim.fr Subject: [dtn-interest] [WISTP'2007] 4 Grants for Young Researchers sponsored by Nokia Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: ******************************************************************* We apologize in advance if you receive multiple copies of this CFP. Please disseminate it to your colleagues that could be interested. ******************************************************************* Workshop in Information Security Theory and Practices 2007: Smart Cards, Mobile and Ubiquitous Computing Systems && A networking meeting to discuss proposals for the EU FP7 Heraklion, Crete, Greece May 8-11, 2007 Workshop URL: http://wistp2007.xlim.fr/ Preliminary Program: http://wistp2007.xlim.fr/CFP.html#Preliminary_program ******************************************************************* 4 Grants for Young Researchers (PhD students or in postdoctoral position) are sponsored by *Nokia*. These grants include accommodation costs (3 nights in the hotel hosting the workshop) and registration fees for the Workshop and the FP7 meeting. The travel is NOT funded. ******************************************************************* Grant application: - Selection will be done by the Organizers and Chairs based on a short CV (1 page maximum), a motivation letter (1 page maximum) and if possible a recommendation letter - Send these documents to wistp2007sec@xlim.fr before the deadline - deadline: 6th of April 2007 - notification of acceptance: 10th of April 2007 The selected applicants will provide one week maximum after the events a short report (5 to 10 pages) written in english to summarize the scientific and organizational aspects (to be discussed with the organizers later). ******************************************************* We hope you will be interested by this event. For further inquiries, please contact the secretariat at wistp2007sec@xlim.fr Best regards, -- Damien Sauveron Received: from smtp.unilim.fr (mail.unilim.fr [164.81.1.45]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2IDDQY31428 for ; Sun, 18 Mar 2007 05:13:27 -0800 Received: from [192.168.0.2] ([84.5.72.27]) (authenticated bits=0) by smtp.unilim.fr (8.13.1/8.13.1) with ESMTP id l2IDDN7a004445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Mar 2007 14:13:23 +0100 Message-ID: <45FD3AF1.5080906@xlim.fr> Date: Sun, 18 Mar 2007 14:13:21 +0100 From: Damien Sauveron User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Univ-Limoges-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (smtp.unilim.fr [164.81.1.45]); Sun, 18 Mar 2007 14:13:23 +0100 (CET) X-Univ-Limoges-MailScanner-Information: Serveur Anti-virus Please contact the SCI, Univ. of Limoges, for more information X-Univ-Limoges-MailScanner: Found to be clean X-Univ-Limoges-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (cached, score=-102.9, requis 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_05 -1.11, NO_RDNS2 0.01, SMTP_AUTH -100.00) X-Univ-Limoges-MailScanner-Envelope-From: damien.sauveron@xlim.fr Subject: [dtn-interest] [WISTP'2007] First Call For Participation Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: ******************************************************************* We apologize in advance if you receive multiple copies of this CFP. Please disseminate it to your colleagues that could be interested. ******************************************************************* Workshop in Information Security Theory and Practices 2007: Smart Cards, Mobile and Ubiquitous Computing Systems && A networking meeting to discuss proposals for the EU FP7 Heraklion, Crete, Greece May 8-11, 2007 Workshop URL: http://wistp2007.xlim.fr/ Preliminary Program: http://wistp2007.xlim.fr/CFP.html#Preliminary_program We are pleased to announce that Prof. Jean-Pierre Hubaux (LCA, EPFL, Switzerland), Prof. Fred Piper (Information Security Group, Royal Holloway University of London, UK), Caspar Bowden (Chief Privacy Advisor EMEA -- Microsoft, UK), Patrick Waters (Head of Research and Development in the Netherlands for Vodafone Group, NL) and two other speakers (to be announced) will deliver keynote speeches. http://wistp2007.xlim.fr/CFP.html#Keynote_Speakers Regarding venue, hotel arrangement, workshop registration and visa request, please visit http://wistp2007.xlim.fr/ for details. http://wistp2007.xlim.fr/CFP/Registration_form.pdf http://wistp2007.xlim.fr/CFP/venue_acc.html Proceedings will be published by Springer LNCS. ******************************************************* WISTP'2007 is: - Co-Sponsored by IFIP TC6 Communications Systems - Co-Sponsored by IFIP WG 8.8 Smart Cards - Co-Sponsored by IFIP WG 11.2 Small System Security - Co-Sponsored by The British Computer Society - In Cooperation with the IEEE Computer Society, Technical Committee on Security and Privacy (TCSP) - In Cooperation with the IEEE Computer Society, Task Force on Information Assurance (TFIA) - In Cooperation with the IEEE Systems, Man, and Cybernetics Society, Technical Committee on Information Assurance & Intelligent Multimedia-Mobile Communications - In Cooperation with the IEEE Systems, Man, and Cybernetics Society, Technical Committee on Systems Safety and Security - In Cooperation with the IEEE Vehicular Technology Society - Supported by the IEEE Region 8 - Supported by the IEEE France Section - Supported by the IEEE UKRI Section & by the IEEE UKRI Section - Computer Society Chapter - Supported by the IEEE Greece Section - Communications Society & Computer Society & VT&AESS Chapters - Supported by the ERCIM - Supported by ACM Special Interest Group on Security, Audit and Control (SIGSAC) - Supported by the EuroSys (European ACM SIGOPS Chapter) - Supported by the ASF (French ACM SIGOPS Chapter) - Supported by the Greek Computer Society - Supported by the ASTI - Supported by the Institute for Systems and Technologies of Information, Control and Communication (INSTICC) - Supported by the SEE - Supported by the GDR CNRS ASR - Supported by the VDE ITG - Supported by the Network of Excellence Euro-NGI - Supported by the European Workshop on Industrial Computer Systems, Technical Committee 7, Safety, Reliability and Security ******************************************************* WISTP2007 Background and Goals: With the rapid technological development of information technologies, computer systems and especially embedded systems are becoming more mobile and ubiquitous, increasingly interfacing with the physical world. Ensuring the security of these complex and yet, resource constraint systems has emerged as one of the most pressing challenges. The aim of this first workshop is to bring together researchers and practitioners in related areas and to encourage interchange and cooperation between the research community and the industrial/consumer community. The workshop will consist of technical paper presentations, one special session for student papers and five invited talks. To contribute to the structuring of the community, a networking meeting to discuss EU FP7 projects proposals will take place just after the workshop. ******************************************************* Topics of interest include, but are not limited to: A. Smart Cards and Trusted Devices Security * Biometrics, National ID cards * Embedded Systems Security and TPMs * Interplay of TPMs and Smart Cards * New Applications for Secure RFID Systems * RFID Systems Security * Smart Card Security * Smart Card Applications B. Ad Hoc and Mobile Networks Security * Ad Hoc Networks Security * Delay-Tolerant Network Security * Domestic Network Security * Mobile Codes Security * Mobile Devices Security * Security Issues in Mobile and Ubiquitous Networks * Security of GSM/GPRS/UMTS Systems * Sensor Networks Security * Vehicular Network Security * Wireless Communication Security (WiFi, WiMAX, WiMedia, others) C. Ubiquitous Computing Systems Security * Distributed Systems Security * Grid Computing Security * Intrusion Detection and Information Filtering * Peer-to-Peer Networks Security D. Security Protocols, Policies and Management for Mobility * Critical Infrastructure (e.g. for Medical or Military Applications) Security * Digital Rights Management (DRM) * Industrial and Multimedia Applications * Information Assurance * Localization Systems Security (Tracking of People and Goods) * New Applications of Secure Systems * Public Administration and Governmental Services * Security Models and Architecture * Security Policies (Human-Computer Interaction and Human Behavior Impact) * Security Protocols (for Identification and Authentication, Confidentiality and Privacy, and Integrity) * Security Measurements * Trust Management ******************************************************* Opportunities for students: To help the students looking for a PhD thesis or a postdoctoral position, we will propose them to add a colorized sticker on their badge. In the same way, we will propose to persons offering these positions to add a sticker with a different color. We hope this mechanism will help to support the exchanges between young and senior researchers. ******************************************************* Thanks to our main sponsors: http://wistp2007.xlim.fr/CFP.html#Main_sponsors Crisp Telecom Eurosmart Elopsys Limousin Expansion Nokia Vodafone WILEY ******************************************************* We hope you will be interested by this event. For further inquiries, please contact the secretariat at wistp2007sec@xlim.fr Best regards, -- Damien Sauveron Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2HKmuY12088 for ; Sat, 17 Mar 2007 12:48:56 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2HKmrTC020249 for ; Sat, 17 Mar 2007 15:48:54 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2HKmqeE003107 for ; Sat, 17 Mar 2007 15:48:53 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Mar 2007 16:48:50 -0400 From: "Peter Lovell" To: "dtn interest" Date: Sat, 17 Mar 2007 16:48:48 -0400 Message-Id: <20070317204848.869887362@127.0.0.1> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2007 20:48:50.0629 (UTC) FILETIME=[AACDDF50:01C768D5] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Sat, 17 Mar 2007 15:48:54 -0500 (CDT) Subject: [dtn-interest] questions re bundle dictionary and flags Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi all, while reviewing the update, an interesting question occurs to me. Section 3.7 "Extension blocks" contains the following ... Any extension block that contains citations of endpoint IDs that are contained in the dictionary of the bundle's primary block should have the "Discard block if it can't be processed" flag set to 1 in the block processing flags field of that extension block. Any extension block that has neither the "Discard block if it can't be processed" flag nor the "Delete bundle if block can't be processed" flag set to 1 in its block processing flags field must not contain any citations of endpoint IDs that are contained in the dictionary of the bundle's primary block. Security blocks will typically, although not always, NOT have these flags set. That is because intermediate forwarding nodes might not be security-aware but we don't want the security blocks deleted. They're not destined for the intermediate nodes so we don't care if those nodes can process them or not. But the way I read this says that, if the flags are not set, the security blocks cannot have EID references in the dictionary. Not even for the source and destination. I'd like to be able to use the size-compression benefit of the dictionary within the security blocks, so I'm wondering about the restriction. Will someone enlighten me why one or other of these flags must be set in order to use EID references? Thanks....Peter Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2GAvPY30082 for ; Fri, 16 Mar 2007 02:57:25 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id BBAE16801C; Fri, 16 Mar 2007 10:57:18 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A06DABB819D; Fri, 16 Mar 2007 10:57:18 +0000 Received: from [134.226.63.88] (cswireless63-88.cs.tcd.ie [134.226.63.88]) by imx2.tcd.ie (Postfix) with ESMTP id AFC8A68085; Fri, 16 Mar 2007 10:57:18 +0000 (GMT) Message-ID: <45FA7862.6060600@cs.tcd.ie> Date: Fri, 16 Mar 2007 10:58:42 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Peter Lovell Cc: Kscott , dtn interest Subject: Re: [dtn-interest] Update to bundle protocol spec. References: <20070315161035.569475999@127.0.0.1> <45F9BC70.6050508@cs.tcd.ie> <20070316065019.1793813737@127.0.0.1> In-Reply-To: <20070316065019.1793813737@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A16DABB819D X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.67.3) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Peter Lovell wrote: > Hi Stephen, > > comments inline ... > > On Thu, Mar 15, 2007, Stephen Farrell wrote: > >> Pete, >> >> Not sure if we want to add that, or not. I'm ok with >> it, but would suggest "not" if anyone has any substantive >> objection. (Late in the day and all that...) > > We did discuss pros and cons and the consensus was that it is OK. There > have not been any objections but I'll certainly revisit this if there > are some. Right. So the question is whether Keith et al want to add this. S. Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2G6srY28673 for ; Thu, 15 Mar 2007 22:54:54 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2G6sojo018427; Fri, 16 Mar 2007 01:54:50 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2G6soIp014554; Fri, 16 Mar 2007 01:54:51 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 02:54:49 -0400 From: "Peter Lovell" To: "Stephen Farrell" Cc: Kscott , "dtn interest" Subject: Re(2): [dtn-interest] Update to bundle protocol spec. Date: Fri, 16 Mar 2007 02:50:19 -0400 Message-Id: <20070316065019.1793813737@127.0.0.1> In-Reply-To: <45F9BC70.6050508@cs.tcd.ie> References: <20070315161035.569475999@127.0.0.1> <45F9BC70.6050508@cs.tcd.ie> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2007 06:54:50.0096 (UTC) FILETIME=[FDE8BF00:01C76797] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Fri, 16 Mar 2007 01:54:51 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi Stephen, comments inline ... On Thu, Mar 15, 2007, Stephen Farrell wrote: > >Pete, > >Not sure if we want to add that, or not. I'm ok with >it, but would suggest "not" if anyone has any substantive >objection. (Late in the day and all that...) We did discuss pros and cons and the consensus was that it is OK. There have not been any objections but I'll certainly revisit this if there are some. The fundamental idea is to preserve block ordering, subject to certain rules. Many of the cases can be handled with requirements in the security spec. But there are some situations where those rules do not apply, and it is that which I deal with in this proposed change. Any node which implements security must comply with the security spec, so our rules there must be observed. So any security-aware forwarding nodes are covered. For this concern to arise, source and destination must also be security-aware -- if they are not then no security applies and there is no issue. However, a forwarding node which is NOT security-aware is required only to follow the rules in the bundle protocol spec and can ignore the security spec. My change deals with that case. >But if we do, it needs rewording - what if a node >deletes a block? (E.g. a CB or some other extension >block.) Can I add a new block in the middle? Do >you only care about blocks that are both received >and transmitted? If changes occur to a security block then the node must be security- aware and the security spec rules apply. I don't want to address those cases in this change because they are more appropriately handled in the security spec, and additional rules apply. If a non-security block is added or deleted then we don't care, as the security spec says that we ignore them (BA does deal with all blocks but if BA is relevant then the node is security-aware and previous comments apply). >Do you only care about blocks that are >both received and transmitted? Exactly ! I'm certainly happy with alternative wording. The essential idea is that the relative ordering of blocks must be maintained as a bundle is forwarded. The wording doesn't need to address additions or deletions as those are covered in other ways. But for all blocks which are received AND transmitted, their relative ordering must be the same. Cheers.....Peter Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2FLZZY25296 for ; Thu, 15 Mar 2007 13:35:35 -0800 Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 07CB6320CF; Thu, 15 Mar 2007 21:35:34 +0000 (GMT) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l2FLZSWX004043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Mar 2007 21:35:29 GMT Message-ID: <45F9BC70.6050508@cs.tcd.ie> Date: Thu, 15 Mar 2007 21:36:48 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Peter Lovell CC: Kscott , dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Update to bundle protocol spec. References: <20070315161035.569475999@127.0.0.1> In-Reply-To: <20070315161035.569475999@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 6326558 - 7150c7369e29 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Pete, Not sure if we want to add that, or not. I'm ok with it, but would suggest "not" if anyone has any substantive objection. (Late in the day and all that...) But if we do, it needs rewording - what if a node deletes a block? (E.g. a CB or some other extension block.) Can I add a new block in the middle? Do you only care about blocks that are both received and transmitted? S. Peter Lovell wrote: > Hi Keith, > > based upon the discussions yesterday, I would like to add this > additional paragraph at the end of section 7, "Security Considerations" ... > > > Bundle security must not be invalidated by forwarding nodes even though > they themselves might not use the Bundle Security Protocol. In > particular, the sequencing of the blocks in a forwarded bundle must not > be changed as it transits a node. Received blocks MUST be transmitted in > the same relative order. > > > On Wed, Mar 14, 2007, Scott, Keith L. wrote: > >> Attached is version 9 of the bundle protocol specification with the >> changes to section 3.3 (Bundle Processing Control Flags) and 3.4 (Block >> Processing Control Flags). These are updates we discussed a while >> back. I'd like to submit this ASAP after the draft submission process >> opens again on the 19th, so please have a look and let me know if you >> see any problems. >> >> thanks, >> >> >> >> --keith > > > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2FGAgY23030 for ; Thu, 15 Mar 2007 08:10:42 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l2FGAdlM018603; Thu, 15 Mar 2007 11:10:39 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l2FGAd8x018113; Thu, 15 Mar 2007 11:10:40 -0500 Received: from [207.151.194.56] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 12:10:38 -0400 From: "Peter Lovell" To: Kscott , Subject: Re: [dtn-interest] Update to bundle protocol spec. Date: Thu, 15 Mar 2007 09:10:35 -0700 Message-Id: <20070315161035.569475999@127.0.0.1> In-Reply-To: References: X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (intel) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2007 16:10:38.0999 (UTC) FILETIME=[78FDC270:01C7671C] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Thu, 15 Mar 2007 11:10:40 -0500 (CDT) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi Keith, based upon the discussions yesterday, I would like to add this additional paragraph at the end of section 7, "Security Considerations" ... Bundle security must not be invalidated by forwarding nodes even though they themselves might not use the Bundle Security Protocol. In particular, the sequencing of the blocks in a forwarded bundle must not be changed as it transits a node. Received blocks MUST be transmitted in the same relative order. On Wed, Mar 14, 2007, Scott, Keith L. wrote: > >Attached is version 9 of the bundle protocol specification with the >changes to section 3.3 (Bundle Processing Control Flags) and 3.4 (Block >Processing Control Flags). These are updates we discussed a while >back. I'd like to submit this ASAP after the draft submission process >opens again on the 19th, so please have a look and let me know if you >see any problems. > >thanks, > > > > --keith Received: from mx2.grc.nasa.gov (mx2.grc.nasa.gov [128.156.11.69]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2EItRY14435 for ; Wed, 14 Mar 2007 10:55:27 -0800 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id A1541C282 for ; Wed, 14 Mar 2007 14:55:21 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2EItJFC028728; Wed, 14 Mar 2007 14:55:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2EItEnW014896; Wed, 14 Mar 2007 14:55:14 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id DxK+hgKFShOb; Wed, 14 Mar 2007 14:55:14 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2EItCgm014887;Wed, 14 Mar 2007 14:55:12 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id B946D4FE4F; Wed, 14 Mar 2007 14:51:38 -0400 (EDT) Date: Wed, 14 Mar 2007 14:51:38 -0400 From: Wesley Eddy To: "Scott, Keith L." Cc: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Update to bundle protocol spec. Message-ID: <20070314185138.GE31778@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:96.13715 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, Mar 14, 2007 at 02:25:47PM -0400, Scott, Keith L. wrote: > Right, I'll do that later, just wanted to make sure we had consensus on > the words first. > To help people evaluate, a colorized rfcdiff versus 08 is here: http://roland.grc.nasa.gov/~weddy/shared/dtnrg/rfcdiff-08-09.html Unfortunately, it picks up a lot of things that are just formatting changes, but it looks like the meaningful changes are in sections 3.4 and 4.8. Is that all? If so, the content changes look good to me. Received: from smtp-mclean.mitre.org (smtpproxy2.mitre.org [192.80.55.71]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2EIQ3Y14207 for ; Wed, 14 Mar 2007 10:26:03 -0800 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l2EIQ3pk007297 for ; Wed, 14 Mar 2007 14:26:03 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id 04C4B1BD80 for ; Wed, 14 Mar 2007 14:26:03 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l2EIQ2B3007271; Wed, 14 Mar 2007 14:26:02 -0400 Received: from IMCSRV1.MITRE.ORG ([129.83.20.158]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 14:26:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76666.3304A1C8" Subject: Re: [dtn-interest] Update to bundle protocol spec. Date: Wed, 14 Mar 2007 14:25:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Update to bundle protocol spec. Thread-Index: AcdmY4W9FctvxIaFQbK9ogLlXm3A8AAAqbjC From: "Scott, Keith L." To: Cc: X-OriginalArrivalTime: 14 Mar 2007 18:26:02.0274 (UTC) FILETIME=[386D6820:01C76666] Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C76666.3304A1C8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 UmlnaHQsIEknbGwgZG8gdGhhdCBsYXRlciwganVzdCB3YW50ZWQgdG8gbWFrZSBzdXJlIHdlIGhh ZCBjb25zZW5zdXMgb24NCnRoZSB3b3JkcyBmaXJzdC4NCg0KICAtLWtlaXRoDQoNCg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogV2VzbGV5IEVkZHkgPHdlZGR5QGdyYy5uYXNh Lmdvdj4NClRvOiBTY290dCwgS2VpdGggTC4NCkNjOiBkdG4taW50ZXJlc3RAbWFpbG1hbi5kdG5y Zy5vcmcgPGR0bi1pbnRlcmVzdEBtYWlsbWFuLmR0bnJnLm9yZz4NClNlbnQ6IFdlZCBNYXIgMTQg MTQ6MDI6NTIgMjAwNw0KU3ViamVjdDogUmU6IFtkdG4taW50ZXJlc3RdIFVwZGF0ZSB0byBidW5k bGUgcHJvdG9jb2wgc3BlYy4NCg0KT24gV2VkLCBNYXIgMTQsIDIwMDcgYXQgMDE6MTg6MTZQTSAt MDQwMCwgU2NvdHQsIEtlaXRoIEwuIHdyb3RlOg0KPiANCj4gQXR0YWNoZWQgaXMgdmVyc2lvbiA5 IG9mIHRoZSBidW5kbGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiB3aXRoIHRoZQ0KPiBjaGFuZ2Vz IHRvIHNlY3Rpb24gMy4zIChCdW5kbGUgUHJvY2Vzc2luZyBDb250cm9sIEZsYWdzKSBhbmQgMy40 DQooQmxvY2sNCj4gUHJvY2Vzc2luZyBDb250cm9sIEZsYWdzKS4gIFRoZXNlIGFyZSB1cGRhdGVz IHdlIGRpc2N1c3NlZCBhIHdoaWxlDQo+IGJhY2suICBJJ2QgbGlrZSB0byBzdWJtaXQgdGhpcyBB U0FQIGFmdGVyIHRoZSBkcmFmdCBzdWJtaXNzaW9uDQpwcm9jZXNzDQo+IG9wZW5zIGFnYWluIG9u IHRoZSAxOXRoLCBzbyBwbGVhc2UgaGF2ZSBhIGxvb2sgYW5kIGxldCBtZSBrbm93IGlmIHlvdQ0K PiBzZWUgYW55IHByb2JsZW1zLg0KDQoNCkkgc3VnZ2VzdCBydW5uaW5nIHRoaXMgdGhyb3VnaCBp ZG5pdHMuICBUaGVyZSBhcmUgYSBidW5jaCBvZiB0aGluZ3MNCnRoYXQNCmdldCBmbGFnZ2VkLCBh bGwgb2Ygd2hpY2ggbG9vayBlYXN5IHRvIGZpeDoNCg0KaWRuaXRzIDIuMDQuMDEgDQoNCnRtcC9k cmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1zcGVjLTA5LnR4dDoNCnRtcC9kcmFmdC1pcnRmLWR0bnJn LWJ1bmRsZS1zcGVjLTA5LnR4dCg1NDYpOiBMaW5lIGhhcyB3ZWlyZCBzcGFjaW5nOg0KJy4uLnRo aW4gYW4gIG9iamVjLi4uJw0KdG1wL2RyYWZ0LWlydGYtZHRucmctYnVuZGxlLXNwZWMtMDkudHh0 KDE1MjIpOiBMaW5lIGlzIHRvbyBsb25nOiB0aGUNCm9mZmVuZGluZyBjaGFyYWN0ZXJzIGFyZSAn bScNCnRtcC9kcmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1zcGVjLTA5LnR4dCgyMDk0KTogTGluZSBo YXMgd2VpcmQgc3BhY2luZzoNCicuLi5jY2VlZGVkICBmbGFnIC4uLicNCnRtcC9kcmFmdC1pcnRm LWR0bnJnLWJ1bmRsZS1zcGVjLTA5LnR4dCgyMDk5KTogTGluZSBoYXMgd2VpcmQgc3BhY2luZzoN CicuLi5jY2VlZGVkICBmbGFnIC4uLicNCnRtcC9kcmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1zcGVj LTA5LnR4dCgyMTE4KTogTGluZSBoYXMgd2VpcmQgc3BhY2luZzoNCicuLi4gICB0aGUgIG9wZXJh dC4uLicNCnRtcC9kcmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1zcGVjLTA5LnR4dCgyMjY5KTogTGlu ZSBpcyB0b28gbG9uZzogdGhlDQpvZmZlbmRpbmcgY2hhcmFjdGVycyBhcmUgJ2cnDQp0bXAvZHJh ZnQtaXJ0Zi1kdG5yZy1idW5kbGUtc3BlYy0wOS50eHQoMjI3NCk6IEZvdW5kIG5vbi1hc2NpaQ0K Y2hhcmFjdGVyICgpIGluIHBvc2l0aW9uIDU1Lg0KdG1wL2RyYWZ0LWlydGYtZHRucmctYnVuZGxl LXNwZWMtMDkudHh0KDIyOTUpOiBMaW5lIGhhcyB3ZWlyZCBzcGFjaW5nOg0KJy4uLnZlcnNpdHkg IG9mICBDLi4uJw0KdG1wL2RyYWZ0LWlydGYtZHRucmctYnVuZGxlLXNwZWMtMDkudHh0KDIzMDAp OiBMaW5lIGhhcyB3ZWlyZCBzcGFjaW5nOg0KJy4uLiAgIG1vc3QgIG9mICB0Li4uJw0KDQoNCiAg Q2hlY2tpbmcgYm9pbGVycGxhdGUgcmVxdWlyZWQgYnkgUkZDIDM5NzggYW5kIDM5NzksIHVwZGF0 ZWQgYnkgUkZDDQo0NzQ4Og0KICAqIFRoaXMgZG9jdW1lbnQgaGFzIGFuIG9yaWdpbmFsIFJGQyAz OTc4IFNlY3Rpb24gNS40IENvcHlyaWdodCBMaW5lLA0KICAgIGluc3RlYWQgb2YgdGhlIG5ld2Vy IElFVEYgVHJ1c3QgQ29weXJpZ2h0IGFjY29yZGluZyB0byBSRkMgNDc0OC4NCiAgKiBUaGlzIGRv Y3VtZW50IGhhcyBhbiBvcmlnaW5hbCBSRkMgMzk3OCBTZWN0aW9uIDUuNSBEaXNjbGFpbWVyLA0K aW5zdGVhZCBvZg0KICAgIHRoZSBuZXdlciBkaXNjbGFpbWVyIHdoaWNoIGluY2x1ZGVzIHRoZSBJ RVRGIFRydXN0IGFjY29yZGluZyB0byBSRkMNCjQ3NDguDQoNCiAgQ2hlY2tpbmcgbml0cyBhY2Nv cmRpbmcgdG8NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtZ3VpZGVsaW5lcy50eHQ6DQog ICogVGhlcmUgaXMgMSBpbnN0YW5jZSBvZiBsaW5lcyB3aXRoIG5vbi1hc2NpaSBjaGFyYWN0ZXJz IGluIHRoZQ0KZG9jdW1lbnQuDQogIC0gTm8gJ0ludGVuZGVkIHN0YXR1cycgaW5kaWNhdGVkIGZv ciB0aGlzIGRvY3VtZW50OyBhc3N1bWluZyBQcm9wb3NlZA0KICAgIFN0YW5kYXJkDQoNCiAgQ2hl Y2tpbmcgbml0cyBhY2NvcmRpbmcgdG8gaHR0cDovL3d3dy5pZXRmLm9yZy9JRC1DaGVja2xpc3Qu aHRtbDoNCiAgKiBUaGVyZSBhcmUgMiBpbnN0YW5jZXMgb2YgdG9vIGxvbmcgbGluZXMgaW4gdGhl IGRvY3VtZW50LCB0aGUNCmxvbmdlc3Qgb25lDQogICAgYmVpbmcgMSBjaGFyYWN0ZXIgaW4gZXhj ZXNzIG9mIDcyLg0KDQogIE1pc2NlbGxhbmVvdXMgd2FybmluZ3M6DQogIC0gVGhlIGNvcHlyaWdo dCB5ZWFyIGluIHRoZSBSRkMgMzk3OCBTZWN0aW9uIDUuNCBDb3B5cmlnaHQgTGluZSBkb2VzDQpu b3QNCiAgICBtYXRjaCB0aGUgY3VycmVudCB5ZWFyDQoNCiAgQ2hlY2tpbmcgcmVmZXJlbmNlcyBm b3IgaW50ZW5kZWQgc3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZA0KICAtIFVudXNlZCBSZWZlcmVu Y2U6ICdSRkMzOTc4JyBpcyBkZWZpbmVkIG9uIGxpbmUgMTk1OCwgYnV0IG5vdA0KcmVmZXJlbmNl ZA0KICAgICdbUkZDMzk3OF0gICBCcmFkbmVyLCBTLiwgIklFVEYgUmlnaHRzIGluIENvbnRyaWJ1 dGlvbnMiLCBCQ1AgNzgsDQpSRkMgMy4uLicNCg0KICAtIFVudXNlZCBSZWZlcmVuY2U6ICdSRkMz OTc5JyBpcyBkZWZpbmVkIG9uIGxpbmUgMTk2MSwgYnV0IG5vdA0KcmVmZXJlbmNlZA0KICAgICdb UkZDMzk3OV0gICBCcmFkbmVyLCBTLiwgIkludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgaW4g SUVURg0KVGVjaG5vbC4uLicNCg0KICAtIFVudXNlZCBSZWZlcmVuY2U6ICc0JyBpcyBkZWZpbmVk IG9uIGxpbmUgMTk4MiwgYnV0IG5vdCByZWZlcmVuY2VkDQogICAgJ1s0XSBNaWxscywgRC4sICJO ZXR3b3JrIFRpbWUgUHJvdG9jb2wgKFZlcnNpb24gMykgU3BlY2lmaWNhdGlvbiwNCkltcGxlLi4u Jw0KDQogICogT2Jzb2xldGUgbm9ybWF0aXZlIHJlZmVyZW5jZTogUkZDIDI3MTcNCiAgLSBPdXRk YXRlZCByZWZlcmVuY2U6IEEgbGF0ZXIgdmVyc2lvbiAoLTA4KSBleGlzdHMgb2YNCiAgICBkcmFm dC1pcnRmLWR0bnJnLWFyY2gtMDMNCiAgLSBPdXRkYXRlZCByZWZlcmVuY2U6IEEgbGF0ZXIgdmVy c2lvbiAoLTAyKSBleGlzdHMgb2YNCiAgICBkcmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1zZWN1cml0 eS0wMA0KICAtIE91dGRhdGVkIHJlZmVyZW5jZTogQSBsYXRlciB2ZXJzaW9uICgtMDIpIGV4aXN0 cyBvZg0KICAgIGRyYWZ0LWlydGYtZHRucmctc2VjLW92ZXJ2aWV3LTAwDQoNCiAgICBTdW1tYXJ5 OiA1IGVycm9ycywgOCB3YXJuaW5ncw0K ------_=_NextPart_001_01C76666.3304A1C8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTEuNTkiPg0KPFRJVExFPlJlOiBbZHRuLWlu dGVyZXN0XSBVcGRhdGUgdG8gYnVuZGxlIHByb3RvY29sIHNwZWMuPC9USVRMRT4NCjwvSEVBRD4N CjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCg0KPFA+ PEZPTlQgU0laRT0yPlJpZ2h0LCBJJ2xsIGRvIHRoYXQgbGF0ZXIsIGp1c3Qgd2FudGVkIHRvIG1h a2Ugc3VyZSB3ZSBoYWQgY29uc2Vuc3VzIG9uIHRoZSB3b3JkcyBmaXJzdC48QlI+DQo8QlI+DQom bmJzcDsgLS1rZWl0aDxCUj4NCjxCUj4NCjxCUj4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS08QlI+DQpGcm9tOiBXZXNsZXkgRWRkeSAmbHQ7d2VkZHlAZ3JjLm5hc2EuZ292Jmd0OzxCUj4N ClRvOiBTY290dCwgS2VpdGggTC48QlI+DQpDYzogZHRuLWludGVyZXN0QG1haWxtYW4uZHRucmcu b3JnICZsdDtkdG4taW50ZXJlc3RAbWFpbG1hbi5kdG5yZy5vcmcmZ3Q7PEJSPg0KU2VudDogV2Vk IE1hciAxNCAxNDowMjo1MiAyMDA3PEJSPg0KU3ViamVjdDogUmU6IFtkdG4taW50ZXJlc3RdIFVw ZGF0ZSB0byBidW5kbGUgcHJvdG9jb2wgc3BlYy48QlI+DQo8QlI+DQpPbiBXZWQsIE1hciAxNCwg MjAwNyBhdCAwMToxODoxNlBNIC0wNDAwLCBTY290dCwgS2VpdGggTC4gd3JvdGU6PEJSPg0KJmd0 OzxCUj4NCiZndDsgQXR0YWNoZWQgaXMgdmVyc2lvbiA5IG9mIHRoZSBidW5kbGUgcHJvdG9jb2wg c3BlY2lmaWNhdGlvbiB3aXRoIHRoZTxCUj4NCiZndDsgY2hhbmdlcyB0byBzZWN0aW9uIDMuMyAo QnVuZGxlIFByb2Nlc3NpbmcgQ29udHJvbCBGbGFncykgYW5kIDMuNCAoQmxvY2s8QlI+DQomZ3Q7 IFByb2Nlc3NpbmcgQ29udHJvbCBGbGFncykuJm5ic3A7IFRoZXNlIGFyZSB1cGRhdGVzIHdlIGRp c2N1c3NlZCBhIHdoaWxlPEJSPg0KJmd0OyBiYWNrLiZuYnNwOyBJJ2QgbGlrZSB0byBzdWJtaXQg dGhpcyBBU0FQIGFmdGVyIHRoZSBkcmFmdCBzdWJtaXNzaW9uIHByb2Nlc3M8QlI+DQomZ3Q7IG9w ZW5zIGFnYWluIG9uIHRoZSAxOXRoLCBzbyBwbGVhc2UgaGF2ZSBhIGxvb2sgYW5kIGxldCBtZSBr bm93IGlmIHlvdTxCUj4NCiZndDsgc2VlIGFueSBwcm9ibGVtcy48QlI+DQo8QlI+DQo8QlI+DQpJ IHN1Z2dlc3QgcnVubmluZyB0aGlzIHRocm91Z2ggaWRuaXRzLiZuYnNwOyBUaGVyZSBhcmUgYSBi dW5jaCBvZiB0aGluZ3MgdGhhdDxCUj4NCmdldCBmbGFnZ2VkLCBhbGwgb2Ygd2hpY2ggbG9vayBl YXN5IHRvIGZpeDo8QlI+DQo8QlI+DQppZG5pdHMgMi4wNC4wMTxCUj4NCjxCUj4NCnRtcC9kcmFm dC1pcnRmLWR0bnJnLWJ1bmRsZS1zcGVjLTA5LnR4dDo8QlI+DQp0bXAvZHJhZnQtaXJ0Zi1kdG5y Zy1idW5kbGUtc3BlYy0wOS50eHQoNTQ2KTogTGluZSBoYXMgd2VpcmQgc3BhY2luZzogJy4uLnRo aW4gYW4mbmJzcDsgb2JqZWMuLi4nPEJSPg0KdG1wL2RyYWZ0LWlydGYtZHRucmctYnVuZGxlLXNw ZWMtMDkudHh0KDE1MjIpOiBMaW5lIGlzIHRvbyBsb25nOiB0aGUgb2ZmZW5kaW5nIGNoYXJhY3Rl cnMgYXJlICdtJzxCUj4NCnRtcC9kcmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1zcGVjLTA5LnR4dCgy MDk0KTogTGluZSBoYXMgd2VpcmQgc3BhY2luZzogJy4uLmNjZWVkZWQmbmJzcDsgZmxhZyAuLi4n PEJSPg0KdG1wL2RyYWZ0LWlydGYtZHRucmctYnVuZGxlLXNwZWMtMDkudHh0KDIwOTkpOiBMaW5l IGhhcyB3ZWlyZCBzcGFjaW5nOiAnLi4uY2NlZWRlZCZuYnNwOyBmbGFnIC4uLic8QlI+DQp0bXAv ZHJhZnQtaXJ0Zi1kdG5yZy1idW5kbGUtc3BlYy0wOS50eHQoMjExOCk6IExpbmUgaGFzIHdlaXJk IHNwYWNpbmc6ICcuLi4mbmJzcDsmbmJzcDsgdGhlJm5ic3A7IG9wZXJhdC4uLic8QlI+DQp0bXAv ZHJhZnQtaXJ0Zi1kdG5yZy1idW5kbGUtc3BlYy0wOS50eHQoMjI2OSk6IExpbmUgaXMgdG9vIGxv bmc6IHRoZSBvZmZlbmRpbmcgY2hhcmFjdGVycyBhcmUgJ2cnPEJSPg0KdG1wL2RyYWZ0LWlydGYt ZHRucmctYnVuZGxlLXNwZWMtMDkudHh0KDIyNzQpOiBGb3VuZCBub24tYXNjaWkgY2hhcmFjdGVy ICgpIGluIHBvc2l0aW9uIDU1LjxCUj4NCnRtcC9kcmFmdC1pcnRmLWR0bnJnLWJ1bmRsZS1zcGVj LTA5LnR4dCgyMjk1KTogTGluZSBoYXMgd2VpcmQgc3BhY2luZzogJy4uLnZlcnNpdHkmbmJzcDsg b2YmbmJzcDsgQy4uLic8QlI+DQp0bXAvZHJhZnQtaXJ0Zi1kdG5yZy1idW5kbGUtc3BlYy0wOS50 eHQoMjMwMCk6IExpbmUgaGFzIHdlaXJkIHNwYWNpbmc6ICcuLi4mbmJzcDsmbmJzcDsgbW9zdCZu YnNwOyBvZiZuYnNwOyB0Li4uJzxCUj4NCjxCUj4NCjxCUj4NCiZuYnNwOyBDaGVja2luZyBib2ls ZXJwbGF0ZSByZXF1aXJlZCBieSBSRkMgMzk3OCBhbmQgMzk3OSwgdXBkYXRlZCBieSBSRkMgNDc0 ODo8QlI+DQombmJzcDsgKiBUaGlzIGRvY3VtZW50IGhhcyBhbiBvcmlnaW5hbCBSRkMgMzk3OCBT ZWN0aW9uIDUuNCBDb3B5cmlnaHQgTGluZSw8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsgaW5zdGVh ZCBvZiB0aGUgbmV3ZXIgSUVURiBUcnVzdCBDb3B5cmlnaHQgYWNjb3JkaW5nIHRvIFJGQyA0NzQ4 LjxCUj4NCiZuYnNwOyAqIFRoaXMgZG9jdW1lbnQgaGFzIGFuIG9yaWdpbmFsIFJGQyAzOTc4IFNl Y3Rpb24gNS41IERpc2NsYWltZXIsIGluc3RlYWQgb2Y8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsg dGhlIG5ld2VyIGRpc2NsYWltZXIgd2hpY2ggaW5jbHVkZXMgdGhlIElFVEYgVHJ1c3QgYWNjb3Jk aW5nIHRvIFJGQyA0NzQ4LjxCUj4NCjxCUj4NCiZuYnNwOyBDaGVja2luZyBuaXRzIGFjY29yZGlu ZyB0byBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWd1aWRlbGluZXMudHh0OjxCUj4NCiZu YnNwOyAqIFRoZXJlIGlzIDEgaW5zdGFuY2Ugb2YgbGluZXMgd2l0aCBub24tYXNjaWkgY2hhcmFj dGVycyBpbiB0aGUgZG9jdW1lbnQuPEJSPg0KJm5ic3A7IC0gTm8gJ0ludGVuZGVkIHN0YXR1cycg aW5kaWNhdGVkIGZvciB0aGlzIGRvY3VtZW50OyBhc3N1bWluZyBQcm9wb3NlZDxCUj4NCiZuYnNw OyZuYnNwOyZuYnNwOyBTdGFuZGFyZDxCUj4NCjxCUj4NCiZuYnNwOyBDaGVja2luZyBuaXRzIGFj Y29yZGluZyB0byBodHRwOi8vd3d3LmlldGYub3JnL0lELUNoZWNrbGlzdC5odG1sOjxCUj4NCiZu YnNwOyAqIFRoZXJlIGFyZSAyIGluc3RhbmNlcyBvZiB0b28gbG9uZyBsaW5lcyBpbiB0aGUgZG9j dW1lbnQsIHRoZSBsb25nZXN0IG9uZTxCUj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBiZWluZyAxIGNo YXJhY3RlciBpbiBleGNlc3Mgb2YgNzIuPEJSPg0KPEJSPg0KJm5ic3A7IE1pc2NlbGxhbmVvdXMg d2FybmluZ3M6PEJSPg0KJm5ic3A7IC0gVGhlIGNvcHlyaWdodCB5ZWFyIGluIHRoZSBSRkMgMzk3 OCBTZWN0aW9uIDUuNCBDb3B5cmlnaHQgTGluZSBkb2VzIG5vdDxCUj4NCiZuYnNwOyZuYnNwOyZu YnNwOyBtYXRjaCB0aGUgY3VycmVudCB5ZWFyPEJSPg0KPEJSPg0KJm5ic3A7IENoZWNraW5nIHJl ZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQ8QlI+DQombmJz cDsgLSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDMzk3OCcgaXMgZGVmaW5lZCBvbiBsaW5lIDE5NTgs IGJ1dCBub3QgcmVmZXJlbmNlZDxCUj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAnW1JGQzM5NzhdJm5i c3A7Jm5ic3A7IEJyYWRuZXIsIFMuLCAmcXVvdDtJRVRGIFJpZ2h0cyBpbiBDb250cmlidXRpb25z JnF1b3Q7LCBCQ1AgNzgsIFJGQyAzLi4uJzxCUj4NCjxCUj4NCiZuYnNwOyAtIFVudXNlZCBSZWZl cmVuY2U6ICdSRkMzOTc5JyBpcyBkZWZpbmVkIG9uIGxpbmUgMTk2MSwgYnV0IG5vdCByZWZlcmVu Y2VkPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICdbUkZDMzk3OV0mbmJzcDsmbmJzcDsgQnJhZG5l ciwgUy4sICZxdW90O0ludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgaW4gSUVURiBUZWNobm9s Li4uJzxCUj4NCjxCUj4NCiZuYnNwOyAtIFVudXNlZCBSZWZlcmVuY2U6ICc0JyBpcyBkZWZpbmVk IG9uIGxpbmUgMTk4MiwgYnV0IG5vdCByZWZlcmVuY2VkPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 ICdbNF0gTWlsbHMsIEQuLCAmcXVvdDtOZXR3b3JrIFRpbWUgUHJvdG9jb2wgKFZlcnNpb24gMykg U3BlY2lmaWNhdGlvbiwgSW1wbGUuLi4nPEJSPg0KPEJSPg0KJm5ic3A7ICogT2Jzb2xldGUgbm9y bWF0aXZlIHJlZmVyZW5jZTogUkZDIDI3MTc8QlI+DQombmJzcDsgLSBPdXRkYXRlZCByZWZlcmVu Y2U6IEEgbGF0ZXIgdmVyc2lvbiAoLTA4KSBleGlzdHMgb2Y8QlI+DQombmJzcDsmbmJzcDsmbmJz cDsgZHJhZnQtaXJ0Zi1kdG5yZy1hcmNoLTAzPEJSPg0KJm5ic3A7IC0gT3V0ZGF0ZWQgcmVmZXJl bmNlOiBBIGxhdGVyIHZlcnNpb24gKC0wMikgZXhpc3RzIG9mPEJSPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7IGRyYWZ0LWlydGYtZHRucmctYnVuZGxlLXNlY3VyaXR5LTAwPEJSPg0KJm5ic3A7IC0gT3V0 ZGF0ZWQgcmVmZXJlbmNlOiBBIGxhdGVyIHZlcnNpb24gKC0wMikgZXhpc3RzIG9mPEJSPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlydGYtZHRucmctc2VjLW92ZXJ2aWV3LTAwPEJSPg0KPEJS Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFN1bW1hcnk6IDUgZXJyb3JzLCA4IHdhcm5pbmdzPEJSPg0K PC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C76666.3304A1C8-- Received: from mx2.grc.nasa.gov (mx2.grc.nasa.gov [128.156.11.69]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2EI6iY13985 for ; Wed, 14 Mar 2007 10:06:45 -0800 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 4B0C2C287 for ; Wed, 14 Mar 2007 14:06:39 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2EI6bov019274; Wed, 14 Mar 2007 14:06:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2EI6UeK019801; Wed, 14 Mar 2007 14:06:30 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id AWsv9QdkVFO1; Wed, 14 Mar 2007 14:06:30 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2EI6Q1Z019764;Wed, 14 Mar 2007 14:06:26 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 1F6A44FE4F; Wed, 14 Mar 2007 14:02:52 -0400 (EDT) Date: Wed, 14 Mar 2007 14:02:52 -0400 From: Wesley Eddy To: "Scott, Keith L." Cc: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Update to bundle protocol spec. Message-ID: <20070314180251.GA31778@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, Mar 14, 2007 at 01:18:16PM -0400, Scott, Keith L. wrote: > > Attached is version 9 of the bundle protocol specification with the > changes to section 3.3 (Bundle Processing Control Flags) and 3.4 (Block > Processing Control Flags). These are updates we discussed a while > back. I'd like to submit this ASAP after the draft submission process > opens again on the 19th, so please have a look and let me know if you > see any problems. I suggest running this through idnits. There are a bunch of things that get flagged, all of which look easy to fix: idnits 2.04.01 tmp/draft-irtf-dtnrg-bundle-spec-09.txt: tmp/draft-irtf-dtnrg-bundle-spec-09.txt(546): Line has weird spacing: '...thin an objec...' tmp/draft-irtf-dtnrg-bundle-spec-09.txt(1522): Line is too long: the offending characters are 'm' tmp/draft-irtf-dtnrg-bundle-spec-09.txt(2094): Line has weird spacing: '...cceeded flag ...' tmp/draft-irtf-dtnrg-bundle-spec-09.txt(2099): Line has weird spacing: '...cceeded flag ...' tmp/draft-irtf-dtnrg-bundle-spec-09.txt(2118): Line has weird spacing: '... the operat...' tmp/draft-irtf-dtnrg-bundle-spec-09.txt(2269): Line is too long: the offending characters are 'g' tmp/draft-irtf-dtnrg-bundle-spec-09.txt(2274): Found non-ascii character () in position 55. tmp/draft-irtf-dtnrg-bundle-spec-09.txt(2295): Line has weird spacing: '...versity of C...' tmp/draft-irtf-dtnrg-bundle-spec-09.txt(2300): Line has weird spacing: '... most of t...' Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: * This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. * This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: * There is 1 instance of lines with non-ascii characters in the document. - No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to http://www.ietf.org/ID-Checklist.html: * There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: - The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year Checking references for intended status: Proposed Standard - Unused Reference: 'RFC3978' is defined on line 1958, but not referenced '[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3...' - Unused Reference: 'RFC3979' is defined on line 1961, but not referenced '[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technol...' - Unused Reference: '4' is defined on line 1982, but not referenced '[4] Mills, D., "Network Time Protocol (Version 3) Specification, Imple...' * Obsolete normative reference: RFC 2717 - Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-arch-03 - Outdated reference: A later version (-02) exists of draft-irtf-dtnrg-bundle-security-00 - Outdated reference: A later version (-02) exists of draft-irtf-dtnrg-sec-overview-00 Summary: 5 errors, 8 warnings Received: from smtp-mclean.mitre.org (smtp-mclean.mitre.org [192.80.55.71]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2EHJSY13535 for ; Wed, 14 Mar 2007 09:19:28 -0800 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l2EHJRHq014244 for ; Wed, 14 Mar 2007 13:19:27 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id 251CF1BD80 for ; Wed, 14 Mar 2007 13:19:27 -0400 (EDT) Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l2EHJMou014164 for ; Wed, 14 Mar 2007 13:19:26 -0400 Received: from IMCSRV1.MITRE.ORG ([129.83.20.158]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 13:19:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7665C.E4EC001B" Date: Wed, 14 Mar 2007 13:18:16 -0400 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Update to bundle protocol spec. Thread-Index: AcdmXL2hTxmSo6aPSkaRbOUt6ltwAQ== From: "Scott, Keith L." To: X-OriginalArrivalTime: 14 Mar 2007 17:19:21.0395 (UTC) FILETIME=[E7B7B830:01C7665C] Subject: [dtn-interest] Update to bundle protocol spec. Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C7665C.E4EC001B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7665C.E4EC001B" ------_=_NextPart_002_01C7665C.E4EC001B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Attached is version 9 of the bundle protocol specification with the changes to section 3.3 (Bundle Processing Control Flags) and 3.4 (Block Processing Control Flags). These are updates we discussed a while back. I'd like to submit this ASAP after the draft submission process opens again on the 19th, so please have a look and let me know if you see any problems. thanks, --keith ------_=_NextPart_002_01C7665C.E4EC001B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Update to bundle protocol spec.

Attached is version 9 of the bundle protocol = specification with the changes to section 3.3 (Bundle Processing Control = Flags) and 3.4 (Block Processing Control Flags).  These are updates = we discussed a while back.  I'd like to submit this ASAP after the = draft submission process opens again on the 19th, so please have a look = and let me know if you see any problems.

thanks,



  --keith

------_=_NextPart_002_01C7665C.E4EC001B-- ------_=_NextPart_001_01C7665C.E4EC001B Content-Type: text/plain; name="draft-irtf-dtnrg-bundle-spec-09.txt" Content-Transfer-Encoding: base64 Content-Description: draft-irtf-dtnrg-bundle-spec-09.txt Content-Disposition: attachment; filename="draft-irtf-dtnrg-bundle-spec-09.txt" SW50ZXJuZXQgRHJhZnQgICAgICBCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAgICAgICAg IE1hcmNoIDIwMDcgDQogDQogDQogIERlbGF5IFRvbGVyYW50IE5ldHdvcmtpbmcgUmVzZWFyY2gg R3JvdXAgICAgSy4gU2NvdHQgDQogIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVGhlIE1JVFJFIENvcnBvcmF0aW9uIA0KICA8ZHJhZnQtaXJ0Zi1kdG5yZy1idW5k bGUtc3BlYy0wOS50eHQ+ICAgICAgICANCiAgTWFyY2ggMjAwNyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTLiBCdXJsZWlnaCANCiAgRXhwaXJlczogU2VwdGVtYmVyIDIwMDcgICAg ICAgICAgICAgICAgICAgICBKZXQgUHJvcHVsc2lvbiANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBMYWJvcmF0b3J5IA0KICAgDQogICAgICAgICAgICAgICAg ICAgICAgQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gDQogICANClN0YXR1cyBvZiB0aGlz IE1lbW8gDQogICANCiAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1 dGhvciByZXByZXNlbnRzIHRoYXQgYW55IA0KICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJ UFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZSANCiAgaGF2ZSBiZWVuIG9yIHdp bGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzIA0KICBh d2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBC Q1AgNzkuIA0KICAgDQogIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2Yg dGhlIEludGVybmV0IEVuZ2luZWVyaW5nIA0KICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFz LCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IA0KICBvdGhlciBncm91cHMgbWF5 IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgRHJhZnRz LiANCiAgIA0KICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeCBtb250aHMgDQogIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IA0KICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSANCiAgbWF0 ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIiAN CiAgIA0KICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNz ZWQgYXQgDQogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4gDQog ICANCiAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBi ZSBhY2Nlc3NlZCBhdCANCiAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogICAN CiAgVGhpcyBkb2N1bWVudCB3YXMgcHJvZHVjZWQgd2l0aGluIHRoZSBJUlRGJ3MgRGVsYXkgVG9s ZXJhbnQgDQogIE5ldHdvcmtpbmcgUmVzZWFyY2ggR3JvdXAgKERUTlJHKSBhbmQgcmVwcmVzZW50 cyB0aGUgY29uc2Vuc3VzIG9mIGFsbCANCiAgb2YgdGhlIGFjdGl2ZSBjb250cmlidXRvcnMgdG8g dGhpcyBHcm91cC4gIFNlZSBodHRwOi8vd3d3LmR0bnJnLm9yZyANCiAgZm9yIG1vcmUgaW5mb3Jt YXRpb24uIA0KICAgDQpBYnN0cmFjdCANCiAgIA0KICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0 aGUgZW5kLXRvLWVuZCBwcm90b2NvbCwgYmxvY2sgZm9ybWF0cywgYW5kIA0KICBhYnN0cmFjdCBz ZXJ2aWNlIGRlc2NyaXB0aW9uIGZvciB0aGUgZXhjaGFuZ2Ugb2YgbWVzc2FnZXMgKGJ1bmRsZXMp IA0KICBpbiBEZWxheSBUb2xlcmFudCBOZXR3b3JraW5nIChEVE4pLiANCiANCkNvbnZlbnRpb25z IHVzZWQgaW4gdGhpcyBkb2N1bWVudCANCiAgIA0KICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsIA0KICAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhp cyANCiAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMt MjExOSBbMV0uIA0KICAgDQoNCg0KIA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAg RXhwaXJlcyAtIFNlcHRlbWJlciAyMDA3ICAgICBbUGFnZSAxXSANCgxJbnRlcm5ldCBEcmFmdCAg ICAgIEJ1bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiAN CiANClRhYmxlIG9mIENvbnRlbnRzIA0KICAgDQogIDEuIEludHJvZHVjdGlvbi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgMi4gU2VydmljZSBE ZXNjcmlwdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IA0K ICAgICAgMi4xICAgICAgRGVmaW5pdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNCANCiAgICAgIDIuMiAgICAgIEltcGxlbWVudGF0aW9uIGFyY2hpdGVjdHVy ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAgICAyLjMgICAgICBTZXJ2aWNlcyBv ZmZlcmVkIGJ5IGJ1bmRsZSBwcm90b2NvbCBhZ2VudHMuLi4uLi4uLi4uLi45IA0KICAzLiBCdW5k bGUgRm9ybWF0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTAgDQogICAgICAzLjEgICAgICBTZWxmLURlbGltaXRpbmcgTnVtZXJpYyBWYWx1ZXMgKFNETlYp Li4uLi4uLi4uLi4uLi4uLjEwIA0KICAgICAgMy4yICAgICAgQ2Fub25pY2FsIEJ1bmRsZSBCbG9j ayBGb3JtYXQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICAgIDMuMyAgICAgIEJ1bmRs ZSBQcm9jZXNzaW5nIENvbnRyb2wgRmxhZ3MuLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTIgDQogICAg ICAzLjQgICAgICBCbG9jayBQcm9jZXNzaW5nIENvbnRyb2wgRmxhZ3MuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjEzIA0KICAgICAgMy41ICAgICAgRW5kcG9pbnQgSURzLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMyANCiAgICAgIDMuNiAgICAgIEZvcm1hdHMgb2YgQnVu ZGxlIEJsb2Nrcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQgDQogICAgICAgIDMuNi4x ICBQcmltYXJ5IEJ1bmRsZSBCbG9jay4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2 IA0KICAgICAgICAzLjYuMiAgQnVuZGxlIFBheWxvYWQgQmxvY2suLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xOSANCiAgICAgIDMuNyAgICAgIEV4dGVuc2lvbiBCbG9ja3MuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkgDQogICAgICAzLjggICAgICBEaWN0aW9u YXJ5IHJldmlzaW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIwIA0KICA0LiBC dW5kbGUgUHJvY2Vzc2luZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMjAgDQogICAgICA0LjEgICAgICBHZW5lcmF0aW9uIG9mIGFkbWluaXN0cmF0aXZlIHJlY29y ZHMuLi4uLi4uLi4uLi4uLi4uLjIwIA0KICAgICAgNC4yICAgICAgQnVuZGxlIHRyYW5zbWlzc2lv bi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMSANCiAgICAgIDQuMyAgICAgIEJ1 bmRsZSBkaXNwYXRjaGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjIgDQog ICAgICA0LjQgICAgICBCdW5kbGUgZm9yd2FyZGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjIyIA0KICAgICAgICA0LjQuMSAgRm9yd2FyZGluZyBDb250cmFpbmRpY2F0ZWQu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMyANCiAgICAgICAgNC40LjIgIEZvcndhcmRpbmcg RmFpbGVkLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjQgDQogICAgICA0LjUg ICAgICBCdW5kbGUgZXhwaXJhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjI0IA0KICAgICAgNC42ICAgICAgQnVuZGxlIHJlY2VwdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4yNCANCiAgICAgIDQuNyAgICAgIExvY2FsIGJ1bmRsZSBkZWxpdmVy eS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjUgDQogICAgICA0LjggICAgICBCdW5k bGUgRnJhZ21lbnRhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI2IA0KICAg ICAgNC45ICAgICAgQXBwbGljYXRpb24gRGF0YSBVbml0IFJlYXNzZW1ibHkuLi4uLi4uLi4uLi4u Li4uLi4uLi4yNyANCiAgICAgIDQuMTAgICAgIEN1c3RvZHkgdHJhbnNmZXIuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjcgDQogICAgICAgIDQuMTAuMSBDdXN0b2R5IGFjY2Vw dGFuY2UuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI4IA0KICAgICAgICA0LjEw LjIgQ3VzdG9keSByZWxlYXNlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4y OSANCiAgICAgIDQuMTEgICAgIEN1c3RvZHkgdHJhbnNmZXIgc3VjY2Vzcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMjkgDQogICAgICA0LjEyICAgICBDdXN0b2R5IHRyYW5zZmVyIGZhaWx1 cmUuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI5IA0KICAgICAgNC4xMyAgICAgQnVuZGxl IGRlbGV0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yOSANCiAgICAg IDQuMTQgICAgIERpc2NhcmRpbmcgYSBidW5kbGUuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMzAgDQogICAgICA0LjE1ICAgICBDYW5jZWxpbmcgYSB0cmFuc21pc3Npb24uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjMwIA0KICAgICAgNC4xNiAgICAgUG9sbGluZy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zMCANCiAgNS4gQWRtaW5pc3Ry YXRpdmUgcmVjb3JkIHByb2Nlc3NpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMwIA0K ICAgICAgNS4xICAgICAgQWRtaW5pc3RyYXRpdmUgcmVjb3Jkcy4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4zMCANCiAgICAgICAgNS4xLjEgIEJ1bmRsZSBTdGF0dXMgUmVwb3J0cy4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzEgDQogICAgICAgIDUuMS4yICBDdXN0b2R5IFNp Z25hbHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjM1IA0KICAgICAgNS4y ICAgICAgR2VuZXJhdGlvbiBvZiBhZG1pbmlzdHJhdGl2ZSByZWNvcmRzLi4uLi4uLi4uLi4uLi4u Li4zNyANCiAgICAgIDUuMyAgICAgIFJlY2VwdGlvbiBvZiBjdXN0b2R5IHNpZ25hbHMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMzcgDQogIDYuIFNlcnZpY2VzIFJlcXVpcmVkIG9mIHRoZSBDb252 ZXJnZW5jZSBMYXllci4uLi4uLi4uLi4uLi4uLi4uLi4zOCANCiAgICAgIDYuMSAgICAgIFRoZSBD b252ZXJnZW5jZSBMYXllci4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzggDQogICAg ICA2LjIgICAgICBTdW1tYXJ5IG9mIENvbnZlcmdlbmNlIExheWVyIFNlcnZpY2VzLi4uLi4uLi4u Li4uLi4uLjM4IA0KICA3LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMzggDQogIDguIElBTkEgQ29uc2lkZXJhdGlvbnMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40MCANCiAgOS4gTm9ybWF0aXZlIFJl ZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQwIA0KIA0K IA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJlcyAtIFNlcHRlbWJlciAyMDA3 ICAgICBbUGFnZSAyXSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1bmRsZSBQcm90b2NvbCBTcGVj aWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCiAgMTAuIEluZm9ybWF0aXZlIFJl ZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40MCANCg0KMS4g ICBJbnRyb2R1Y3Rpb24gDQogICANCiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdmVyc2lvbiA1 IG9mIHRoZSBEZWxheSBUb2xlcmFudCANCiAgTmV0d29ya2luZyAoRFROKSAiYnVuZGxlIiBwcm90 b2NvbCAoQlApLiAgRGVsYXkgVG9sZXJhbnQgTmV0d29ya2luZyANCiAgaXMgYW4gZW5kLXRvLWVu ZCBhcmNoaXRlY3R1cmUgcHJvdmlkaW5nIGNvbW11bmljYXRpb25zIGluIGFuZC9vciANCiAgdGhy b3VnaCBoaWdobHkgc3RyZXNzZWQgZW52aXJvbm1lbnRzLiAgU3RyZXNzZWQgbmV0d29ya2luZyAN CiAgZW52aXJvbm1lbnRzIGluY2x1ZGUgdGhvc2Ugd2l0aCBpbnRlcm1pdHRlbnQgY29ubmVjdGl2 aXR5LCBsYXJnZSANCiAgYW5kL29yIHZhcmlhYmxlIGRlbGF5cywgYW5kIGhpZ2ggYml0IGVycm9y IHJhdGVzLiAgVG8gcHJvdmlkZSBpdHMgDQogIHNlcnZpY2VzLCBCUCBzaXRzIGF0IHRoZSBhcHBs aWNhdGlvbiBsYXllciBvZiBzb21lIG51bWJlciBvZiANCiAgY29uc3RpdHVlbnQgaW50ZXJuZXRz LCBmb3JtaW5nIGEgc3RvcmUtYW5kLWZvcndhcmQgb3ZlcmxheSBuZXR3b3JrLiAgDQogIEtleSBj YXBhYmlsaXRpZXMgb2YgQlAgaW5jbHVkZTogDQogICANCiAgICBvIEN1c3RvZHktYmFzZWQgcmV0 cmFuc21pc3Npb24gDQogICAgbyBBYmlsaXR5IHRvIGNvcGUgd2l0aCBpbnRlcm1pdHRlbnQgY29u bmVjdGl2aXR5IA0KICAgIG8gQWJpbGl0eSB0byB0YWtlIGFkdmFudGFnZSBvZiBzY2hlZHVsZWQs IHByZWRpY3RlZCwgYW5kIA0KICBvcHBvcnR1bmlzdGljIGNvbm5lY3Rpdml0eSAoaW4gYWRkaXRp b24gdG8gY29udGludW91cyBjb25uZWN0aXZpdHkpIA0KICAgIG8gTGF0ZSBiaW5kaW5nIG9mIG92 ZXJsYXkgbmV0d29yayBlbmRwb2ludCBpZGVudGlmaWVycyB0byANCiAgICBjb25zdGl0dWVudCBp bnRlcm5ldCBhZGRyZXNzZXMgDQogICANCiAgRm9yIGRlc2NyaXB0aW9ucyBvZiB0aGVzZSBjYXBh YmlsaXRpZXMgYW5kIHRoZSByYXRpb25hbGUgZm9yIHRoZSBEVE4gDQogIGFyY2hpdGVjdHVyZSwg c2VlIFsyXSBhbmQgWzhdLiAgWzNdIGNvbnRhaW5zIGEgdHV0b3JpYWwtbGV2ZWwgDQogIG92ZXJ2 aWV3IG9mIERUTiBjb25jZXB0cy4gDQogICANCiAgQlAncyBsb2NhdGlvbiB3aXRoaW4gdGhlIHN0 YW5kYXJkIHByb3RvY29sIHN0YWNrIGlzIGFzIHNob3duIGluIA0KICBGaWd1cmUgMS4gIEJQIHVz ZXMgdGhlICJuYXRpdmUiIGludGVybmV0IHByb3RvY29scyBmb3IgY29tbXVuaWNhdGlvbnMgDQog IHdpdGhpbiBhIGdpdmVuIGludGVybmV0LiAgTm90ZSB0aGF0ICJpbnRlcm5ldCIgaW4gdGhlIHBy ZWNlZGluZyBpcyANCiAgdXNlZCBpbiBhIGdlbmVyYWwgc2Vuc2UgYW5kIGRvZXMgbm90IG5lY2Vz c2FyaWx5IHJlZmVyIHRvIFRDUC9JUC4gIA0KICBUaGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIGNv bW1vbiBidW5kbGUgcHJvdG9jb2wgYW5kIGEgc3BlY2lmaWMgDQogIGludGVybmV0d29yayBwcm90 b2NvbCBzdWl0ZSBpcyB0ZXJtZWQgYSAiY29udmVyZ2VuY2UgbGF5ZXIgYWRhcHRlciIuICANCiAg RmlndXJlIDEgc2hvd3MgdGhyZWUgZGlzdGluY3QgdHJhbnNwb3J0IGFuZCBuZXR3b3JrIHByb3Rv Y29scyANCiAgKGRlbm90ZWQgVDEvTjEsIFQyLE4yLCBhbmQgVDMvTjMpLiANCiAgIA0KICArLS0t LS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0rICANCiAgfCAgIEJQIGFwcCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgIEJQIGFwcCAgfCAgDQogICstLS0tLS0tLS12LXwgICArLT4+Pj4+Pj4+Pj52 LSsgICAgICstPj4+Pj4+Pj4+PnYtKyAgICstXi0tLS0tLS0tLSsgIA0KICB8ICAgIEJQICAgdiB8 ICAgfCBeICAgIEJQICAgdiB8ICAgICB8IF4gICAgQlAgICB2IHwgICB8IF4gICBCUCAgICB8ICAN CiAgKy0tLS0tLS0tLXYtKyAgICstXi0tLS0tLS0tLXYtKyAgICAgKy1eLS0tLS0tLS0tdi0rICAg Ky1eLS0tLS0tLS0tKyAgDQogIHwgVHJhbnMxICB2IHwgICArIF4gIFQxL1QyICB2IHwgICAgICsg XiAgVDIvVDMgIHYgfCAgIHwgXiAgVHJhbnMzIHwgIA0KICArLS0tLS0tLS0tdi0rICAgKy1eLS0t LS0tLS0tdi0rICAgICArLV4tLS0tLS0tLS12ICsgICArLV4tLS0tLS0tLS0rICANCiAgfCBOZXQx ICAgIHYgfCAgIHwgXiAgTjEvTjIgIHYgfCAgICAgfCBeICBOMi9OMyAgdiB8ICAgfCBeICBOZXQz ICAgfCAgDQogICstLS0tLS0tLS12LSsgICArLV4tLS0tLS0tLS12ICsgICAgICstXi0tLS0tLS0t LXYtKyAgICstXi0tLS0tLS0tLSsgIA0KICB8ICAgICAgICAgPj4+Pj4+Pj5eICAgICAgICAgPj4+ Pj4+Pj4+Pl4gICAgICAgICA+Pj4+Pj4+Pl4gICAgICAgICB8ICANCiAgKy0tLS0tLS0tLS0tKyAg ICstLS0tLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tKyAgDQog IHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgIHwgIA0KICB8PC0tLSBBbiBpbnRlcm5ldCAgLS0tPnwgICAgICAgICAgICAgICAg ICAgfDwtLS0gQW4gaW50ZXJuZXQgIC0tLT58ICANCiAgfCAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfCANCiAgIA0KICBGaWd1 cmUgMTogVGhlIGJ1bmRsZSBwcm90b2NvbCBzaXRzIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBv ZiB0aGUgDQogIEludGVybmV0IG1vZGVsLiANCiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWln aCAgICAgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwNyAgICAgW1BhZ2UgM10gDQoMSW50ZXJuZXQg RHJhZnQgICAgICBCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIw MDcgDQogDQogDQogICANCiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGZvcm1hdCBvZiB0 aGUgcHJvdG9jb2wgZGF0YSB1bml0cyAoY2FsbGVkIA0KICBidW5kbGVzKSBwYXNzZWQgYmV0d2Vl biBlbnRpdGllcyBwYXJ0aWNpcGF0aW5nIGluIEJQIGNvbW11bmljYXRpb25zLiAgDQogIFRoZSBl bnRpdGllcyBhcmUgcmVmZXJyZWQgdG8gYXMgImJ1bmRsZSBub2RlcyIuICBUaGlzIGRvY3VtZW50 IGRvZXMgDQogIG5vdCBhZGRyZXNzOiANCiAgIA0KICAgIG8gT3BlcmF0aW9ucyBpbiB0aGUgY29u dmVyZ2VuY2UgbGF5ZXIgYWRhcHRlcnMgdGhhdCBidW5kbGUgbm9kZXMgdXNlIA0KICB0byB0cmFu c3BvcnQgZGF0YSB0aHJvdWdoIHNwZWNpZmljIHR5cGVzIG9mIGludGVybmV0LiAgKEhvd2V2ZXIs IHRoZSANCiAgZG9jdW1lbnQgZG9lcyBkaXNjdXNzIHRoZSBzZXJ2aWNlcyB0aGF0IG11c3QgYmUg cHJvdmlkZWQgYnkgZWFjaCANCiAgYWRhcHRlciBhdCB0aGUgY29udmVyZ2VuY2UgbGF5ZXIuKSAN CiAgIA0KICAgIG8gVGhlIGJ1bmRsZSByb3V0aW5nIGFsZ29yaXRobS4gDQogICANCiAgICBvIE1l Y2hhbmlzbXMgZm9yIHBvcHVsYXRpbmcgdGhlIHJvdXRpbmcgb3IgZm9yd2FyZGluZyBpbmZvcm1h dGlvbiANCiAgYmFzZXMgb2YgYnVuZGxlIG5vZGVzLiANCiAgIA0KMi4gICBTZXJ2aWNlIERlc2Ny aXB0aW9uIA0KICAgDQoyLjEgRGVmaW5pdGlvbnMgDQogICANCiAgQnVuZGxlIC0gQSBidW5kbGUg aXMgYSBwcm90b2NvbCBkYXRhIHVuaXQgb2YgdGhlIERUTiBidW5kbGUgcHJvdG9jb2wuICANCiAg RWFjaCBidW5kbGUgY29tcHJpc2VzIGEgc2VxdWVuY2Ugb2YgdHdvIG9yIG1vcmUgImJsb2NrcyIg b2YgcHJvdG9jb2wgDQogIGRhdGEsIHdoaWNoIHNlcnZlIHZhcmlvdXMgcHVycG9zZXMuICBNdWx0 aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgDQogIGJ1bmRsZSAodGhlIHNhbWUgdW5pdCBvZiBE VE4gcHJvdG9jb2wgZGF0YSkgbWlnaHQgZXhpc3QgY29uY3VycmVudGx5IA0KICBpbiBkaWZmZXJl bnQgcGFydHMgb2YgYSBuZXR3b3JrIC0gcG9zc2libHkgaW4gZGlmZmVyZW50IA0KICByZXByZXNl bnRhdGlvbnMgLSBpbiB0aGUgbWVtb3J5IGxvY2FsIHRvIG9uZSBvciBtb3JlIGJ1bmRsZSBub2Rl cyANCiAgYW5kL29yIGluIHRyYW5zaXQgYmV0d2VlbiBub2Rlcy4gIEluIHRoZSBjb250ZXh0IG9m IHRoZSBvcGVyYXRpb24gb2YgDQogIGEgYnVuZGxlIG5vZGUsIGEgYnVuZGxlIGlzIGFuIGluc3Rh bmNlIG9mIHNvbWUgYnVuZGxlIGluIHRoZSBuZXR3b3JrIA0KICB0aGF0IGlzIGluIHRoYXQgbm9k ZSdzIGxvY2FsIG1lbW9yeS4gIA0KICAgDQogIEJ1bmRsZSBwYXlsb2FkIC0gQSBidW5kbGUgcGF5 bG9hZCAob3Igc2ltcGx5ICJwYXlsb2FkIikgaXMgdGhlIA0KICBhcHBsaWNhdGlvbiBkYXRhIHdo b3NlIGNvbnZleWFuY2UgdG8gdGhlIGJ1bmRsZSdzIGRlc3RpbmF0aW9uIGlzIHRoZSANCiAgcHVy cG9zZSBmb3IgdGhlIHRyYW5zbWlzc2lvbiBvZiBhIGdpdmVuIGJ1bmRsZS4gIFRoZSB0ZXJtcyAi YnVuZGxlIA0KICBjb250ZW50IiwgImJ1bmRsZSBwYXlsb2FkIiwgYW5kICJwYXlsb2FkIiBhcmUg dXNlZCBpbnRlcmNoYW5nZWFibHkgaW4gDQogIHRoaXMgZG9jdW1lbnQuICBUaGUgIm5vbWluYWwi IHBheWxvYWQgZm9yIGEgYnVuZGxlIGZvcndhcmRlZCBpbiANCiAgcmVzcG9uc2UgdG8gYSBidW5k bGUgdHJhbnNtaXNzaW9uIHJlcXVlc3QgaXMgdGhlIGFwcGxpY2F0aW9uIGRhdGEgDQogIHVuaXQg d2hvc2UgbG9jYXRpb24gaXMgcHJvdmlkZWQgYXMgYSBwYXJhbWV0ZXIgdG8gdGhhdCByZXF1ZXN0 LiAgVGhlIA0KICBub21pbmFsIHBheWxvYWQgZm9yIGEgYnVuZGxlIGZvcndhcmRlZCBpbiByZXNw b25zZSB0byByZWNlcHRpb24gb2YgDQogIHRoYXQgYnVuZGxlIGlzIHRoZSBwYXlsb2FkIG9mIHRo ZSByZWNlaXZlZCBidW5kbGUuIA0KICAgDQogIEZyYWdtZW50IC0gQSBmcmFnbWVudCBpcyBhIGJ1 bmRsZSB3aG9zZSBwYXlsb2FkIGJsb2NrIGNvbnRhaW5zIGEgDQogIGZyYWdtZW50YXJ5IHBheWxv YWQuICBBIGZyYWdtZW50YXJ5IHBheWxvYWQgaXMgZWl0aGVyIHRoZSBmaXJzdCBOIA0KICBieXRl cyBvciB0aGUgbGFzdCBOIGJ5dGVzIG9mIHNvbWUgb3RoZXIgcGF5bG9hZCAtIGVpdGhlciBhIG5v bWluYWwgDQogIHBheWxvYWQgb3IgYSBmcmFnbWVudGFyeSBwYXlsb2FkIC0gb2YgbGVuZ3RoIE0s IHN1Y2ggdGhhdCAwIDwgTiA8IE0uIA0KICAgDQogIEJ1bmRsZSBub2RlIC0gQSBidW5kbGUgbm9k ZSAob3IsIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9jdW1lbnQsIA0KICBzaW1wbHkgYSAibm9k ZSIpIGlzIGFueSBlbnRpdHkgdGhhdCBjYW4gc2VuZCBhbmQvb3IgcmVjZWl2ZSBidW5kbGVzLiAg DQogIEluIHRoZSBtb3N0IGZhbWlsaWFyIGNhc2UgYSBidW5kbGUgbm9kZSBpcyBpbnN0YW50aWF0 ZWQgYXMgYSBzaW5nbGUgDQogIHByb2Nlc3MgcnVubmluZyBvbiBhIGdlbmVyYWwtcHVycG9zZSBj b21wdXRlciwgYnV0IGluIGdlbmVyYWwgdGhlIA0KICBkZWZpbml0aW9uIGlzIG1lYW50IHRvIGJl IGJyb2FkZXI6IGEgYnVuZGxlIG5vZGUgbWlnaHQgYWx0ZXJuYXRpdmVseSANCiAgYmUgYSB0aHJl YWQsIGFuIG9iamVjdCBpbiBhbiBvYmplY3Qtb3JpZW50ZWQgb3BlcmF0aW5nIHN5c3RlbSwgYSAN CiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4cGlyZXMgLSBTZXB0ZW1iZXIg MjAwNyAgICAgW1BhZ2UgNF0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICBCdW5kbGUgUHJvdG9jb2wg U3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcgDQogDQogDQogIHNwZWNpYWwtcHVycG9z ZSBoYXJkd2FyZSBkZXZpY2UsIGV0Yy4gIEVhY2ggYnVuZGxlIG5vZGUgaGFzIHRocmVlIA0KICBj b25jZXB0dWFsIGNvbXBvbmVudHMsIGRlZmluZWQgYmVsb3c6IGEgImJ1bmRsZSBwcm90b2NvbCBh Z2VudCIsIGEgDQogIHNldCBvZiB6ZXJvIG9yIG1vcmUgImNvbnZlcmdlbmNlIGxheWVyIGFkYXB0 ZXJzIiwgYW5kIGFuICJhcHBsaWNhdGlvbiANCiAgYWdlbnQiLiANCiAgIA0KICBCdW5kbGUgcHJv dG9jb2wgYWdlbnQgLSBUaGUgYnVuZGxlIHByb3RvY29sIGFnZW50IChCUEEpIG9mIGEgbm9kZSBp cyANCiAgdGhlIG5vZGUgY29tcG9uZW50IHRoYXQgb2ZmZXJzIHRoZSBCUCBzZXJ2aWNlcyBhbmQg ZXhlY3V0ZXMgdGhlIA0KICBwcm9jZWR1cmVzIG9mIHRoZSBCdW5kbGUgUHJvdG9jb2wuICBUaGUg bWFubmVyIGluIHdoaWNoIGl0IGRvZXMgc28gaXMgDQogIHdob2xseSBhbiBpbXBsZW1lbnRhdGlv biBtYXR0ZXIuICBGb3IgZXhhbXBsZSwgQlBBIGZ1bmN0aW9uYWxpdHkgDQogIG1pZ2h0IGJlIGNv ZGVkIGludG8gZWFjaCBub2RlIGluZGl2aWR1YWxseTsgaXQgbWlnaHQgYmUgaW1wbGVtZW50ZWQg DQogIGFzIGEgc2hhcmVkIGxpYnJhcnkgdGhhdCBpcyB1c2VkIGluIGNvbW1vbiBieSBhbnkgbnVt YmVyIG9mIGJ1bmRsZSANCiAgbm9kZXMgb24gYSBzaW5nbGUgY29tcHV0ZXI7IGl0IG1pZ2h0IGJl IGltcGxlbWVudGVkIGFzIGEgZGFlbW9uIHdob3NlIA0KICBzZXJ2aWNlcyBhcmUgaW52b2tlZCB2 aWEgaW50ZXItcHJvY2VzcyBvciBuZXR3b3JrIGNvbW11bmljYXRpb24gYnkgDQogIGFueSBudW1i ZXIgb2YgYnVuZGxlIG5vZGVzIG9uIG9uZSBvciBtb3JlIGNvbXB1dGVyczsgaXQgbWlnaHQgYmUg DQogIGltcGxlbWVudGVkIGluIGhhcmR3YXJlLiANCiAgIA0KICBDb252ZXJnZW5jZSBsYXllciBh ZGFwdGVycyAtIEEgY29udmVyZ2VuY2UgbGF5ZXIgYWRhcHRlciAoQ0xBKSBzZW5kcyANCiAgYW5k IHJlY2VpdmVzIGJ1bmRsZXMgb24gYmVoYWxmIG9mIHRoZSBCUEEsIHV0aWxpemluZyB0aGUgc2Vy dmljZXMgb2YgDQogIHNvbWUgJ25hdGl2ZScgaW50ZXJuZXQgcHJvdG9jb2wgdGhhdCBpcyBzdXBw b3J0ZWQgaW4gb25lIG9mIHRoZSANCiAgaW50ZXJuZXRzIHdpdGhpbiB3aGljaCB0aGUgbm9kZSBp cyBmdW5jdGlvbmFsbHkgbG9jYXRlZC4gIFRoZSBtYW5uZXIgDQogIGluIHdoaWNoIGEgQ0xBIHNl bmRzIGFuZCByZWNlaXZlcyBidW5kbGVzIGlzIHdob2xseSBhbiBpbXBsZW1lbnRhdGlvbiANCiAg bWF0dGVyLCBleGFjdGx5IGFzIGRlc2NyaWJlZCBmb3IgdGhlIEJQQS4gIA0KICAgDQogIEFwcGxp Y2F0aW9uIGFnZW50IC0gVGhlIGFwcGxpY2F0aW9uIGFnZW50IChBQSkgb2YgYSBub2RlIGlzIHRo ZSBub2RlIA0KICBjb21wb25lbnQgdGhhdCB1dGlsaXplcyB0aGUgQlAgc2VydmljZXMgdG8gZWZm ZWN0IGNvbW11bmljYXRpb24gZm9yIA0KICBzb21lIHB1cnBvc2UuICBUaGUgYXBwbGljYXRpb24g YWdlbnQgaW4gdHVybiBoYXMgdHdvIGVsZW1lbnRzLCBhbiANCiAgYWRtaW5pc3RyYXRpdmUgZWxl bWVudCBhbmQgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZWxlbWVudC4gIFRoZSANCiAgYXBwbGlj YXRpb24tc3BlY2lmaWMgZWxlbWVudCBvZiBhbiBBQSBjb25zdHJ1Y3RzLCByZXF1ZXN0cyANCiAg dHJhbnNtaXNzaW9uIG9mLCBhY2NlcHRzIGRlbGl2ZXJ5IG9mLCBhbmQgcHJvY2Vzc2VzIGFwcGxp Y2F0aW9uLQ0KICBzcGVjaWZpYyBhcHBsaWNhdGlvbiBkYXRhIHVuaXRzOyB0aGUgb25seSBpbnRl cmZhY2UgYmV0d2VlbiB0aGUgQlBBIA0KICBhbmQgdGhlIGFwcGxpY2F0aW9uLXNwZWNpZmljIGVs ZW1lbnQgb2YgdGhlIEFBIGlzIHRoZSBCUCBzZXJ2aWNlIA0KICBpbnRlcmZhY2UuICBUaGUgYWRt aW5pc3RyYXRpdmUgZWxlbWVudCBvZiBhbiBBQSBjb25zdHJ1Y3RzIGFuZCANCiAgcmVxdWVzdHMg dHJhbnNtaXNzaW9uIG9mIGFkbWluaXN0cmF0aXZlIHJlY29yZHMgKHN0YXR1cyByZXBvcnRzIGFu ZCANCiAgY3VzdG9keSBzaWduYWxzKSwgYW5kIGl0IGFjY2VwdHMgZGVsaXZlcnkgb2YgYW5kIHBy b2Nlc3NlcyBhbnkgDQogIGN1c3RvZHkgc2lnbmFscyB0aGF0IHRoZSBub2RlIHJlY2VpdmVzLiAg SW4gYWRkaXRpb24gdG8gdGhlIEJQIA0KICBzZXJ2aWNlIGludGVyZmFjZSwgdGhlcmUgaXMgYSAo Y29uY2VwdHVhbCkgcHJpdmF0ZSBjb250cm9sIGludGVyZmFjZSANCiAgYmV0d2VlbiB0aGUgQlBB IGFuZCB0aGUgYWRtaW5pc3RyYXRpdmUgZWxlbWVudCBvZiB0aGUgQUEgdGhhdCBlbmFibGVzIA0K ICBlYWNoIHRvIGRpcmVjdCB0aGUgb3RoZXIgdG8gdGFrZSBhY3Rpb24gdW5kZXIgc3BlY2lmaWMg Y2lyY3Vtc3RhbmNlcy4gIA0KICBJbiB0aGUgY2FzZSBvZiBhIG5vZGUgdGhhdCBzZXJ2ZXMgc2lt cGx5IGFzIGEgInJvdXRlciIgaW4gdGhlIG92ZXJsYXkgDQogIG5ldHdvcmssIHRoZSBBQSBtYXkg aGF2ZSBubyBhcHBsaWNhdGlvbi1zcGVjaWZpYyBlbGVtZW50IGF0IGFsbC4gIFRoZSANCiAgYXBw bGljYXRpb24tc3BlY2lmaWMgZWxlbWVudHMgb2Ygb3RoZXIgbm9kZXMnIEFBcyBtYXkgcGVyZm9y bSANCiAgYXJiaXRyYXJpbHkgY29tcGxleCBhcHBsaWNhdGlvbiBmdW5jdGlvbnMsIHBlcmhhcHMg ZXZlbiBvZmZlcmluZyANCiAgbXVsdGlwbGV4ZWQgRFROIGNvbW11bmljYXRpb24gc2VydmljZXMg dG8gYSBudW1iZXIgb2Ygb3RoZXIgDQogIGFwcGxpY2F0aW9ucy4gIEFzIHdpdGggdGhlIEJQQSwg dGhlIG1hbm5lciBpbiB3aGljaCB0aGUgQUEgcGVyZm9ybXMgDQogIGl0cyBmdW5jdGlvbnMgaXMg d2hvbGx5IGFuIGltcGxlbWVudGF0aW9uIG1hdHRlcjsgaW4gcGFydGljdWxhciwgdGhlIA0KICBh ZG1pbmlzdHJhdGl2ZSBlbGVtZW50IG9mIGFuIEFBIG1pZ2h0IGJlIGJ1aWx0IGludG8gdGhlIGxp YnJhcnkgb3IgDQogIGRhZW1vbiBvciBoYXJkd2FyZSB0aGF0IGltcGxlbWVudHMgdGhlIEJQQSwg YW5kIHRoZSBhcHBsaWNhdGlvbi0NCiAgc3BlY2lmaWMgZWxlbWVudCBvZiBhbiBBQSBtaWdodCBi ZSBpbXBsZW1lbnRlZCBlaXRoZXIgaW4gc29mdHdhcmUgb3IgDQogIGluIGhhcmR3YXJlLiAgDQog ICANCiAgQnVuZGxlIGVuZHBvaW50IC0gQSBidW5kbGUgZW5kcG9pbnQgKG9yIHNpbXBseSAiZW5k cG9pbnQiKSBpcyBhIHNldCANCiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4 cGlyZXMgLSBTZXB0ZW1iZXIgMjAwNyAgICAgW1BhZ2UgNV0gDQoMSW50ZXJuZXQgRHJhZnQgICAg ICBCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcgDQogDQog DQogIG9mIHplcm8gb3IgbW9yZSBidW5kbGUgbm9kZXMgdGhhdCBhbGwgaWRlbnRpZnkgdGhlbXNl bHZlcyBmb3IgQlAgDQogIHB1cnBvc2VzIGJ5IHNvbWUgc2luZ2xlIHRleHQgc3RyaW5nLCBjYWxs ZWQgYSAiYnVuZGxlIGVuZHBvaW50IElEIiANCiAgKG9yLCBpbiB0aGlzIGRvY3VtZW50LCBzaW1w bHkgImVuZHBvaW50IElEIjsgZW5kcG9pbnQgSURzIGFyZSANCiAgZGVzY3JpYmVkIGluIGRldGFp bCBpbiAzLjUgYmVsb3cpLiAgIFRoZSBzcGVjaWFsIGNhc2Ugb2YgYW4gZW5kcG9pbnQgDQogIHRo YXQgbmV2ZXIgY29udGFpbnMgbW9yZSB0aGFuIG9uZSBub2RlIGlzIHRlcm1lZCBhICJzaW5nbGV0 b24iIA0KICBlbmRwb2ludDsgZXZlcnkgYnVuZGxlIG5vZGUgbXVzdCBiZSBhIG1lbWJlciBvZiBh dCBsZWFzdCBvbmUgDQogIHNpbmdsZXRvbiBlbmRwb2ludC4gIFNpbmdsZXRvbnMgYXJlIHRoZSBt b3N0IGZhbWlsaWFyIHNvcnQgb2YgDQogIGVuZHBvaW50LCBidXQgaW4gZ2VuZXJhbCB0aGUgZW5k cG9pbnQgbm90aW9uIGlzIG1lYW50IHRvIGJlIGJyb2FkZXIuICANCiAgRm9yIGV4YW1wbGUsIHRo ZSBub2RlcyBpbiBhIHNlbnNvciBuZXR3b3JrIG1pZ2h0IGNvbnN0aXR1dGUgYSBzZXQgb2YgDQog IGJ1bmRsZSBub2RlcyB0aGF0IGlkZW50aWZ5IHRoZW1zZWx2ZXMgYnkgYSBzaW5nbGUgY29tbW9u IGVuZHBvaW50IElEIA0KICBhbmQgdGh1cyBmb3JtIGEgc2luZ2xlIGJ1bmRsZSBlbmRwb2ludC4g ICoqTm90ZSoqIHRvbyB0aGF0IGEgZ2l2ZW4gDQogIGJ1bmRsZSBub2RlIG1pZ2h0IGlkZW50aWZ5 IGl0c2VsZiBieSBtdWx0aXBsZSBlbmRwb2ludCBJRHMgYW5kIHRodXMgDQogIGJlIGEgbWVtYmVy IG9mIG11bHRpcGxlIGJ1bmRsZSBlbmRwb2ludHMuIA0KICAgDQogIEZvcndhcmRpbmcgLSBXaGVu IHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgb2YgYSBub2RlIGRldGVybWluZXMgdGhhdCANCiAg YSBidW5kbGUgbXVzdCBiZSAiZm9yd2FyZGVkIiB0byBhbiBlbmRwb2ludCwgaXQgY2F1c2VzIHRo ZSBidW5kbGUgdG8gDQogIGJlIHNlbnQgdG8gYWxsIG9mIHRoZSBub2RlcyB0aGF0IHRoZSBidW5k bGUgcHJvdG9jb2wgYWdlbnQgY3VycmVudGx5IA0KICBiZWxpZXZlcyBhcmUgaW4gdGhlICJtaW5p bXVtIHJlY2VwdGlvbiBncm91cCIgb2YgdGhhdCBlbmRwb2ludC4gIFRoZSANCiAgbWluaW11bSBy ZWNlcHRpb24gZ3JvdXAgb2YgYW4gZW5kcG9pbnQgbWF5IGJlIGFueSBvbmUgb2YgdGhlIA0KICBm b2xsb3dpbmc6IChhKSBBTEwgb2YgdGhlIG5vZGVzIHJlZ2lzdGVyZWQgaW4gYW4gZW5kcG9pbnQg dGhhdCBpcyANCiAgcGVybWl0dGVkIHRvIGNvbnRhaW4gbXVsdGlwbGUgbm9kZXMgKGluIHdoaWNo IGNhc2UgZm9yd2FyZGluZyB0byB0aGUgDQogIGVuZHBvaW50IGlzIGZ1bmN0aW9uYWxseSBzaW1p bGFyIHRvICJtdWx0aWNhc3QiIG9wZXJhdGlvbnMgaW4gdGhlIA0KICBJbnRlcm5ldCwgdGhvdWdo IHBvc3NpYmx5IHZlcnkgZGlmZmVyZW50IGluIGltcGxlbWVudGF0aW9uKTsgKGIpIEFOWSANCiAg TiBvZiB0aGUgbm9kZXMgcmVnaXN0ZXJlZCBpbiBhbiBlbmRwb2ludCB0aGF0IGlzIHBlcm1pdHRl ZCB0byBjb250YWluIA0KICBtdWx0aXBsZSBub2Rlcywgd2hlcmUgTiBpcyBpbiB0aGUgcmFuZ2Ug ZnJvbSB6ZXJvIHRvIHRoZSBjYXJkaW5hbGl0eSANCiAgb2YgdGhlIGVuZHBvaW50IChpbiB3aGlj aCBjYXNlIGZvcndhcmRpbmcgdG8gdGhlIGVuZHBvaW50IGlzIA0KICBmdW5jdGlvbmFsbHkgc2lt aWxhciB0byAiYW55Y2FzdCIgb3BlcmF0aW9ucyBpbiB0aGUgSW50ZXJuZXQpOyAoYykgDQogIFRI RSBTT0xFIE5PREUgcmVnaXN0ZXJlZCBpbiBhIHNpbmdsZXRvbiBlbmRwb2ludCAoaW4gd2hpY2gg Y2FzZSANCiAgZm9yd2FyZGluZyB0byB0aGUgZW5kcG9pbnQgaXMgZnVuY3Rpb25hbGx5IHNpbWls YXIgdG8gInVuaWNhc3QiIA0KICBvcGVyYXRpb25zIGluIHRoZSBJbnRlcm5ldCkuICBUaGUgbmF0 dXJlIG9mIHRoZSBtaW5pbXVtIHJlY2VwdGlvbiANCiAgZ3JvdXAgZm9yIGEgZ2l2ZW4gZW5kcG9p bnQgY2FuIGJlIGRldGVybWluZWQgZnJvbSB0aGUgZW5kcG9pbnQncyBJRCANCiAgKGFnYWluLCBz ZWUgMy41IGJlbG93KTogZm9yIHNvbWUgZW5kcG9pbnQgSUQgInNjaGVtZXMiLCB0aGUgbmF0dXJl IG9mIA0KICB0aGUgbWluaW11bSByZWNlcHRpb24gZ3JvdXAgaXMgZml4ZWQgLSBpbiBhIG1hbm5l ciB0aGF0IGlzIGRlZmluZWQgYnkgDQogIHRoZSBzY2hlbWUgLSBmb3IgYWxsIGVuZHBvaW50cyBp ZGVudGlmaWVkIHVuZGVyIHRoZSBzY2hlbWU7IGZvciBvdGhlciANCiAgc2NoZW1lcywgdGhlIG5h dHVyZSBvZiB0aGUgbWluaW11bSByZWNlcHRpb24gZ3JvdXAgaXMgaW5kaWNhdGVkIGJ5IA0KICBz b21lIGxleGljYWwgZmVhdHVyZSBvZiB0aGUgInNjaGVtZS1zcGVjaWZpYyBwYXJ0IiBvZiB0aGUg ZW5kcG9pbnQgDQogIElELCBpbiBhIG1hbm5lciB0aGF0IGlzIGRlZmluZWQgYnkgdGhlIHNjaGVt ZS4gDQogICANCiAgUmVnaXN0cmF0aW9uIC0gQSByZWdpc3RyYXRpb24gaXMgdGhlIHN0YXRlIG1h Y2hpbmUgY2hhcmFjdGVyaXppbmcgYSANCiAgZ2l2ZW4gbm9kZSdzIG1lbWJlcnNoaXAgaW4gYSBn aXZlbiBlbmRwb2ludC4gIEFueSBudW1iZXIgb2YgDQogIHJlZ2lzdHJhdGlvbnMgbWF5IGJlIGNv bmN1cnJlbnRseSBhc3NvY2lhdGVkIHdpdGggYSBnaXZlbiBlbmRwb2ludCwgDQogIGFuZCBhbnkg bnVtYmVyIG9mIHJlZ2lzdHJhdGlvbnMgbWF5IGJlIGNvbmN1cnJlbnRseSBhc3NvY2lhdGVkIHdp dGggYSANCiAgZ2l2ZW4gbm9kZS4gIEFueSBzaW5nbGUgcmVnaXN0cmF0aW9uIG11c3QgYXQgYW55 IHRpbWUgYmUgaW4gb25lIG9mIA0KICB0d28gc3RhdGVzOiBBY3RpdmUsIFBhc3NpdmUuICBBIHJl Z2lzdHJhdGlvbiBhbHdheXMgaGFzIGFuIGFzc29jaWF0ZWQgDQogICJkZWxpdmVyeSBmYWlsdXJl IGFjdGlvbiIsIHRoZSBhY3Rpb24gdGhhdCBpcyB0byBiZSB0YWtlbiB3aGVuIGEgDQogIGJ1bmRs ZSB0aGF0IGlzICJkZWxpdmVyYWJsZSIgKHNlZSBiZWxvdykgc3ViamVjdCB0byB0aGF0IHJlZ2lz dHJhdGlvbiANCiAgaXMgcmVjZWl2ZWQgYXQgYSB0aW1lIHdoZW4gdGhlIHJlZ2lzdHJhdGlvbiBp cyBpbiB0aGUgUGFzc2l2ZSBzdGF0ZS4gIA0KICBEZWxpdmVyeSBmYWlsdXJlIGFjdGlvbiBtdXN0 IGJlIG9uZSBvZiB0aGUgZm9sbG93aW5nOiANCiAgIA0KICAgbyBkZWZlciAiZGVsaXZlcnkiIChz ZWUgYmVsb3cpIG9mIHRoZSBidW5kbGUgc3ViamVjdCB0byB0aGlzIA0KICByZWdpc3RyYXRpb24g dW50aWwgKGEpIHRoaXMgYnVuZGxlIGlzIHRoZSBsZWFzdCByZWNlbnRseSByZWNlaXZlZCBvZiAN CiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4cGlyZXMgLSBTZXB0ZW1iZXIg MjAwNyAgICAgW1BhZ2UgNl0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICBCdW5kbGUgUHJvdG9jb2wg U3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcgDQogDQogDQogIGFsbCBidW5kbGVzIGN1 cnJlbnRseSBkZWxpdmVyYWJsZSBzdWJqZWN0IHRvIHRoaXMgcmVnaXN0cmF0aW9uIGFuZCANCiAg KGIpIGVpdGhlciB0aGUgcmVnaXN0cmF0aW9uIGlzIHBvbGxlZCBvciBlbHNlIHRoZSByZWdpc3Ry YXRpb24gaXMgaW4gDQogIEFjdGl2ZSBzdGF0ZTsgDQogICANCiAgIG8gImFiYW5kb24iIChzZWUg YmVsb3cpIGRlbGl2ZXJ5IG9mIHRoZSBidW5kbGUgc3ViamVjdCB0byB0aGlzIA0KICByZWdpc3Ry YXRpb24uIA0KICAgDQogIEFuIGFkZGl0aW9uYWwgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgZGVs aXZlcnkgZGVmZXJyYWwgcHJvY2VkdXJlIG1heSANCiAgb3B0aW9uYWxseSBiZSBhc3NvY2lhdGVk IHdpdGggdGhlIHJlZ2lzdHJhdGlvbi4gIFdoaWxlIHRoZSBzdGF0ZSBvZiBhIA0KICByZWdpc3Ry YXRpb24gaXMgQWN0aXZlLCByZWNlcHRpb24gb2YgYSBidW5kbGUgdGhhdCBpcyBkZWxpdmVyYWJs ZSANCiAgc3ViamVjdCB0byB0aGlzIHJlZ2lzdHJhdGlvbiBtdXN0IGNhdXNlIHRoZSBidW5kbGUg dG8gYmUgZGVsaXZlcmVkIA0KICBhdXRvbWF0aWNhbGx5IGFzIHNvb24gYXMgaXQgaXMgdGhlIGxl YXN0IHJlY2VudGx5IHJlY2VpdmVkIGJ1bmRsZSANCiAgdGhhdCBpcyBjdXJyZW50bHkgZGVsaXZl cmFibGUgc3ViamVjdCB0byB0aGUgcmVnaXN0cmF0aW9uLiAgV2hpbGUgdGhlIA0KICBzdGF0ZSBv ZiBhIHJlZ2lzdHJhdGlvbiBpcyBQYXNzaXZlLCByZWNlcHRpb24gb2YgYSBidW5kbGUgdGhhdCBp cyANCiAgZGVsaXZlcmFibGUgc3ViamVjdCB0byB0aGlzIHJlZ2lzdHJhdGlvbiBtdXN0IGNhdXNl IGRlbGl2ZXJ5IG9mIHRoZSANCiAgYnVuZGxlIHRvIGJlIGFiYW5kb25lZCBvciBkZWZlcnJlZCBh cyBtYW5kYXRlZCBieSB0aGUgcmVnaXN0cmF0aW9uJ3MgDQogIGN1cnJlbnQgZGVsaXZlcnkgZmFp bHVyZSBhY3Rpb247IGluIHRoZSBsYXR0ZXIgY2FzZSwgYW55IGFkZGl0aW9uYWwgDQogIGRlbGl2 ZXJ5IGRlZmVycmFsIHByb2NlZHVyZSBhc3NvY2lhdGVkIHdpdGggdGhlIHJlZ2lzdHJhdGlvbiBt dXN0IA0KICBhbHNvIGJlIHBlcmZvcm1lZC4gDQogICANCiAgRGVsaXZlcnkgLSBVcG9uIHJlY2Vw dGlvbiwgdGhlIHByb2Nlc3Npbmcgb2YgYSBidW5kbGUgdGhhdCBoYXMgYmVlbiANCiAgc2VudCB0 byBhIGdpdmVuIG5vZGUgZGVwZW5kcyBvbiB3aGV0aGVyIG9yIG5vdCB0aGUgcmVjZWl2aW5nIG5v ZGUgaXMgDQogIHJlZ2lzdGVyZWQgaW4gdGhlIGJ1bmRsZSdzIGRlc3RpbmF0aW9uIGVuZHBvaW50 OyBpZiBpdCBpcywgYW5kIGlmIHRoZSANCiAgcGF5bG9hZCBvZiB0aGUgYnVuZGxlIGlzIG5vbi1m cmFnbWVudGFyeSAocG9zc2libHkgYXMgYSByZXN1bHQgb2YgDQogIHN1Y2Nlc3NmdWwgcGF5bG9h ZCByZWFzc2VtYmx5IGZyb20gZnJhZ21lbnRhcnkgcGF5bG9hZHMsIGluY2x1ZGluZyANCiAgdGhl IG9yaWdpbmFsIHBheWxvYWQgb2YgdGhlIHJlY2VpdmVkIGJ1bmRsZSksIHRoZW4gdGhlIGJ1bmRs ZSBpcyANCiAgbm9ybWFsbHkgImRlbGl2ZXJlZCIgdG8gdGhlIG5vZGUncyBhcHBsaWNhdGlvbiBh Z2VudCBzdWJqZWN0IHRvIHRoZSANCiAgcmVnaXN0cmF0aW9uIGNoYXJhY3Rlcml6aW5nIHRoZSBu b2RlJ3MgbWVtYmVyc2hpcCBpbiB0aGUgZGVzdGluYXRpb24gDQogIGVuZHBvaW50LiAgQSBidW5k bGUgaXMgY29uc2lkZXJlZCB0byBoYXZlIGJlZW4gZGVsaXZlcmVkIGF0IGEgbm9kZSANCiAgc3Vi amVjdCB0byBhIHJlZ2lzdHJhdGlvbiBhcyBzb29uIGFzIHRoZSBhcHBsaWNhdGlvbiBkYXRhIHVu aXQgdGhhdCANCiAgaXMgdGhlIHBheWxvYWQgb2YgdGhlIGJ1bmRsZSwgdG9nZXRoZXIgd2l0aCB0 aGUgdmFsdWUgb2YgdGhlIGJ1bmRsZSdzIA0KICAiQWNrbm93bGVkZ2VtZW50IGJ5IGFwcGxpY2F0 aW9uIGlzIHJlcXVlc3RlZCIgZmxhZyBhbmQgYW55IG90aGVyIA0KICByZWxldmFudCBtZXRhZGF0 YSAoYW4gaW1wbGVtZW50YXRpb24gbWF0dGVyKSwgaGFzIGJlZW4gcHJlc2VudGVkIHRvIA0KICB0 aGUgbm9kZSdzIGFwcGxpY2F0aW9uIGFnZW50IGluIGEgbWFubmVyIGNvbnNpc3RlbnQgd2l0aCB0 aGUgc3RhdGUgb2YgDQogIHRoYXQgcmVnaXN0cmF0aW9uIGFuZCwgYXMgYXBwbGljYWJsZSwgdGhl IHJlZ2lzdHJhdGlvbidzIGRlbGl2ZXJ5IA0KICBmYWlsdXJlIGFjdGlvbi4gDQogICANCiAgRGVs aXZlcmFiaWxpdHksIEFiYW5kb25tZW50IC0gQSBidW5kbGUgaXMgY29uc2lkZXJlZCAiZGVsaXZl cmFibGUiIA0KICBzdWJqZWN0IHRvIGEgcmVnaXN0cmF0aW9uIGlmIGFuZCBvbmx5IGlmIChhKSB0 aGUgYnVuZGxlJ3MgZGVzdGluYXRpb24gDQogIGVuZHBvaW50IGlzIHRoZSBlbmRwb2ludCB3aXRo IHdoaWNoIHRoZSByZWdpc3RyYXRpb24gaXMgYXNzb2NpYXRlZCwgDQogIChiKSB0aGUgYnVuZGxl IGhhcyBub3QgeWV0IGJlZW4gZGVsaXZlcmVkIHN1YmplY3QgdG8gdGhpcyANCiAgcmVnaXN0cmF0 aW9uLCBhbmQgKGMpIGRlbGl2ZXJ5IG9mIHRoZSBidW5kbGUgc3ViamVjdCB0byB0aGlzIA0KICBy ZWdpc3RyYXRpb24gaGFzIG5vdCBiZWVuIGFiYW5kb25lZC4gIFRvICJhYmFuZG9uIiBkZWxpdmVy eSBvZiBhIA0KICBidW5kbGUgc3ViamVjdCB0byBhIHJlZ2lzdHJhdGlvbiBpcyBzaW1wbHkgdG8g ZGVjbGFyZSBpdCBubyBsb25nZXIgDQogIGRlbGl2ZXJhYmxlIHN1YmplY3QgdG8gdGhhdCByZWdp c3RyYXRpb247IG5vcm1hbGx5IG9ubHkgDQogIHJlZ2lzdHJhdGlvbnMnIHJlZ2lzdGVyZWQgZGVs aXZlcnkgZmFpbHVyZSBhY3Rpb25zIGNhdXNlIGRlbGl2ZXJpZXMgDQogIHRvIGJlIGFiYW5kb25l ZC4gDQogICANCiAgRGVsZXRpb24sIERpc2NhcmRpbmcgLSBBIGJ1bmRsZSBwcm90b2NvbCBhZ2Vu dCAiZGlzY2FyZHMiIGEgYnVuZGxlIGJ5IA0KICBzaW1wbHkgY2Vhc2luZyBhbGwgb3BlcmF0aW9u cyBvbiB0aGUgYnVuZGxlIGFuZCBmdW5jdGlvbmFsbHkgZXJhc2luZyANCiAgYWxsIHJlZmVyZW5j ZXMgdG8gaXQ7IHRoZSBzcGVjaWZpYyBwcm9jZWR1cmVzIGJ5IHdoaWNoIHRoaXMgaXMgDQogDQog DQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAgICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDcg ICAgIFtQYWdlIDddIA0KDEludGVybmV0IERyYWZ0ICAgICAgQnVuZGxlIFByb3RvY29sIFNwZWNp ZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0KIA0KIA0KICBhY2NvbXBsaXNoZWQgYXJlIGFu IGltcGxlbWVudGF0aW9uIG1hdHRlci4gIEJ1bmRsZXMgYXJlIGRpc2NhcmRlZCANCiAgc2lsZW50 bHksIGkuZS4sIHRoZSBkaXNjYXJkaW5nIG9mIGEgYnVuZGxlIGRvZXMgbm90IHJlc3VsdCBpbiAN CiAgZ2VuZXJhdGlvbiBvZiBhbiBhZG1pbmlzdHJhdGl2ZSByZWNvcmQuICAiUmV0ZW50aW9uIGNv bnN0cmFpbnRzIiBhcmUgDQogIGVsZW1lbnRzIG9mIGJ1bmRsZSBzdGF0ZSB0aGF0IHByZXZlbnQg YSBidW5kbGUgZnJvbSBiZWluZyBkaXNjYXJkZWQ7IA0KICBhIGJ1bmRsZSBjYW5ub3QgYmUgZGlz Y2FyZGVkIHdoaWxlIGl0IGhhcyBhbnkgcmV0ZW50aW9uIGNvbnN0cmFpbnRzLiAgDQogIEEgYnVu ZGxlIHByb3RvY29sIGFnZW50ICJkZWxldGVzIiBhIGJ1bmRsZSBpbiByZXNwb25zZSB0byBzb21l IA0KICBhbm9tYWxvdXMgY29uZGl0aW9uIGJ5IG5vdGlmeWluZyB0aGUgYnVuZGxlJ3MgcmVwb3J0 LXRvIGVuZHBvaW50IG9mIA0KICB0aGUgZGVsZXRpb24gKHByb3ZpZGVkIHN1Y2ggbm90aWZpY2F0 aW9uIGlzIHdhcnJhbnRlZDsgc2VlIDQuMTMgZm9yIA0KICBkZXRhaWxzKSBhbmQgdGhlbiBhcmJp dHJhcmlseSByZW1vdmluZyBhbGwgb2YgdGhlIGJ1bmRsZSdzIHJldGVudGlvbiANCiAgY29uc3Ry YWludHMsIGVuYWJsaW5nIHRoZSBidW5kbGUgdG8gYmUgZGlzY2FyZGVkLiAgDQogICANCiAgVHJh bnNtaXNzaW9uIC0gQSB0cmFuc21pc3Npb24gaXMgYSBzdXN0YWluZWQgZWZmb3J0IGJ5IGEgbm9k ZSdzIA0KICBidW5kbGUgcHJvdG9jb2wgYWdlbnQgdG8gY2F1c2UgYSBidW5kbGUgdG8gYmUgc2Vu dCB0byBhbGwgbm9kZXMgaW4gDQogIHRoZSBtaW5pbXVtIHJlY2VwdGlvbiBncm91cCBvZiBzb21l IGVuZHBvaW50ICh3aGljaCBtYXkgYmUgdGhlIA0KICBidW5kbGUncyBkZXN0aW5hdGlvbiBvciBt YXkgYmUgc29tZSBpbnRlcm1lZGlhdGUgZm9yd2FyZGluZyBlbmRwb2ludCkgDQogIGluIHJlc3Bv bnNlIHRvIGEgdHJhbnNtaXNzaW9uIHJlcXVlc3QgaXNzdWVkIGJ5IHRoZSBub2RlJ3MgDQogIGFw cGxpY2F0aW9uIGFnZW50LiAgQW55IG51bWJlciBvZiB0cmFuc21pc3Npb25zIG1heSBiZSBjb25j dXJyZW50bHkgDQogIHVuZGVydGFrZW4gYnkgdGhlIGJ1bmRsZSBwcm90b2NvbCBhZ2VudCBvZiBh IGdpdmVuIG5vZGUuIA0KICAgDQogIEN1c3RvZHkgLSBUbyAiYWNjZXB0IGN1c3RvZHkiIHVwb24g Zm9yd2FyZGluZyBhIGJ1bmRsZSBpcyB0byBjb21taXQgDQogIHRvIHJldGFpbmluZyBhIGNvcHkg b2YgdGhlIGJ1bmRsZSAtIHBvc3NpYmx5IHJlLWZvcndhcmRpbmcgdGhlIGJ1bmRsZSANCiAgd2hl biB0aGUgbmVjZXNzaXR5IHRvIGRvIHNvIGlzIGRldGVybWluZWQgLSB1bnRpbCBjdXN0b2R5IG9m IHRoYXQgDQogIGJ1bmRsZSBpcyAicmVsZWFzZWQiLiAgQ3VzdG9keSBvZiBhIGJ1bmRsZSB3aG9z ZSBkZXN0aW5hdGlvbiBpcyBhIA0KICBzaW5nbGV0b24gZW5kcG9pbnQgaXMgcmVsZWFzZWQgd2hl biBlaXRoZXIgKGEpIG5vdGlmaWNhdGlvbiBpcyANCiAgcmVjZWl2ZWQgdGhhdCBzb21lIG90aGVy IG5vZGUgaGFzIGFjY2VwdGVkIGN1c3RvZHkgb2YgdGhlIHNhbWUgDQogIGJ1bmRsZSwgKGIpIG5v dGlmaWNhdGlvbiBpcyByZWNlaXZlZCB0aGF0IHRoZSBidW5kbGUgaGFzIGJlZW4gDQogIGRlbGl2 ZXJlZCBhdCB0aGUgKHNvbGUpIG5vZGUgcmVnaXN0ZXJlZCBpbiB0aGUgYnVuZGxlJ3MgZGVzdGlu YXRpb24gDQogIGVuZHBvaW50LCBvciAoYykgdGhlIGJ1bmRsZSBpcyBleHBsaWNpdGx5IGRlbGV0 ZWQgZm9yIHNvbWUgcmVhc29uLCANCiAgc3VjaCBhcyBsaWZldGltZSBleHBpcmF0aW9uLiAgVGhl IGNvbmRpdGlvbihzKSB1bmRlciB3aGljaCBjdXN0b2R5IG9mIA0KICBhIGJ1bmRsZSB3aG9zZSBk ZXN0aW5hdGlvbiBpcyBub3QgYSBzaW5nbGV0b24gZW5kcG9pbnQgbWF5IGJlIA0KICByZWxlYXNl ZCBhcmUgbm90IGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiAgVG8gInJlZnVzZSBjdXN0 b2R5IiANCiAgb2YgYSBidW5kbGUgaXMgdG8gZGVjaWRlIG5vdCB0byBhY2NlcHQgY3VzdG9keSBv ZiB0aGUgYnVuZGxlLiAgQSANCiAgImN1c3RvZGlhbCBub2RlIiBvZiBhIGJ1bmRsZSBpcyBhIG5v ZGUgdGhhdCBoYXMgYWNjZXB0ZWQgY3VzdG9keSBvZiANCiAgdGhlIGJ1bmRsZSBhbmQgaGFzIG5v dCB5ZXQgcmVsZWFzZWQgdGhhdCBjdXN0b2R5LiAgQSAiY3VzdG9kaWFuIiBvZiBhIA0KICBidW5k bGUgaXMgYSBzaW5nbGV0b24gZW5kcG9pbnQgd2hvc2Ugc29sZSBtZW1iZXIgaXMgb25lIG9mIHRo ZSANCiAgYnVuZGxlJ3MgY3VzdG9kaWFsIG5vZGVzLiANCiAgIA0KMi4yIEltcGxlbWVudGF0aW9u IGFyY2hpdGVjdHVyZXMgDQogICANCiAgVGhlIGFib3ZlIGRlZmluaXRpb25zIGFyZSBpbnRlbmRl ZCB0byBlbmFibGUgdGhlIGJ1bmRsZSBwcm90b2NvbCdzIA0KICBvcGVyYXRpb25zIHRvIGJlIHNw ZWNpZmllZCBpbiBhIG1hbm5lciB0aGF0IG1pbmltaXplcyBiaWFzIHRvd2FyZCBhbnkgDQogIHBh cnRpY3VsYXIgaW1wbGVtZW50YXRpb24gYXJjaGl0ZWN0dXJlLiAgVG8gaWxsdXN0cmF0ZSB0aGUg cmFuZ2Ugb2YgDQogIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb24gbW9kZWxzIHRoYXQgbWln aHQgY29uZm9ybSB0byB0aGlzIA0KICBzcGVjaWZpY2F0aW9uLCBmb3VyIGV4YW1wbGUgYXJjaGl0 ZWN0dXJlcyBhcmUgYnJpZWZseSBkZXNjcmliZWQgDQogIGJlbG93LiANCiAgIA0KICBhKSBCdW5k bGUgcHJvdG9jb2wgYXBwbGljYXRpb24gc2VydmVyIA0KICAgDQogIEEgc2luZ2xlIGJ1bmRsZSBw cm90b2NvbCBhcHBsaWNhdGlvbiBzZXJ2ZXIsIGNvbnN0aXR1dGluZyBhIHNpbmdsZSANCiAgYnVu ZGxlIG5vZGUsIHJ1bnMgYXMgYSBkYWVtb24gcHJvY2VzcyBvbiBlYWNoIGNvbXB1dGVyLiAgVGhl IGRhZW1vbidzIA0KICBmdW5jdGlvbmFsaXR5IGluY2x1ZGVzIGFsbCBmdW5jdGlvbnMgb2YgdGhl IGJ1bmRsZSBwcm90b2NvbCBhZ2VudCwgDQogDQogDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2gg ICAgICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDcgICAgIFtQYWdlIDhdIA0KDEludGVybmV0IERy YWZ0ICAgICAgQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3 IA0KIA0KIA0KICBhbGwgY29udmVyZ2VuY2UgbGF5ZXIgYWRhcHRlcnMsIGFuZCBib3RoIHRoZSBh ZG1pbmlzdHJhdGl2ZSBhbmQgDQogIGFwcGxpY2F0aW9uLXNwZWNpZmljIGVsZW1lbnRzIG9mIHRo ZSBhcHBsaWNhdGlvbiBhZ2VudC4gIFRoZSANCiAgYXBwbGljYXRpb24tc3BlY2lmaWMgZWxlbWVu dCBvZiB0aGUgYXBwbGljYXRpb24gYWdlbnQgZnVuY3Rpb25zIGFzIGEgDQogIHNlcnZlciwgb2Zm ZXJpbmcgYnVuZGxlIHByb3RvY29sIHNlcnZpY2Ugb3ZlciBhIGxvY2FsIGFyZWEgbmV0d29yazog DQogIGl0IHJlc3BvbmRzIHRvIHJlbW90ZSBwcm9jZWR1cmUgY2FsbHMgZnJvbSBhcHBsaWNhdGlv biBwcm9jZXNzZXMgKG9uIA0KICB0aGUgc2FtZSBjb21wdXRlciBhbmQvb3IgcmVtb3RlIGNvbXB1 dGVycykgdGhhdCBuZWVkIHRvIGNvbW11bmljYXRlIA0KICB2aWEgdGhlIGJ1bmRsZSBwcm90b2Nv bC4gIFRoZSBzZXJ2ZXIgc3VwcG9ydHMgaXRzIGNsaWVudHMgYnkgY3JlYXRpbmcgDQogIGEgbmV3 IChjb25jZXB0dWFsKSBub2RlIGZvciBlYWNoIG9uZSBhbmQgcmVnaXN0ZXJpbmcgZWFjaCBzdWNo IG5vZGUgDQogIGluIGEgY2xpZW50LXNwZWNpZmllZCBlbmRwb2ludDsgdGhlIGNvbmNlcHR1YWwg bm9kZXMgbWFuYWdlZCBieSB0aGUgDQogIHNlcnZlciBmdW5jdGlvbiBhcyBjbGllbnRzJyBCdW5k bGUgUHJvdG9jb2wgc2VydmljZSBhY2Nlc3MgcG9pbnRzLiANCiAgIA0KICBiKSBQZWVyIGFwcGxp Y2F0aW9uIG5vZGVzIA0KICAgDQogIEFueSBudW1iZXIgb2YgYnVuZGxlIHByb3RvY29sIGFwcGxp Y2F0aW9uIHByb2Nlc3NlcywgZWFjaCBvbmUgDQogIGNvbnN0aXR1dGluZyBhIHNpbmdsZSBidW5k bGUgbm9kZSwgcnVuIGluIGFkLWhvYyBmYXNoaW9uIG9uIGVhY2ggDQogIGNvbXB1dGVyLiAgVGhl IGZ1bmN0aW9uYWxpdHkgb2YgdGhlIGJ1bmRsZSBwcm90b2NvbCBhZ2VudCwgYWxsIA0KICBjb252 ZXJnZW5jZSBsYXllciBhZGFwdGVycywgYW5kIHRoZSBhZG1pbmlzdHJhdGl2ZSBlbGVtZW50IG9m IHRoZSANCiAgYXBwbGljYXRpb24gYWdlbnQgaXMgcHJvdmlkZWQgYnkgYSBsaWJyYXJ5IHRvIHdo aWNoIGVhY2ggbm9kZSBwcm9jZXNzIA0KICBpcyBkeW5hbWljYWxseSBsaW5rZWQgYXQgcnVuIHRp bWU7IHRoZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBlbGVtZW50IA0KICBvZiBlYWNoIG5vZGUncyBh cHBsaWNhdGlvbiBhZ2VudCBpcyBub2RlLXNwZWNpZmljIGFwcGxpY2F0aW9uIGNvZGUuICANCiAg IA0KICBjKSBTZW5zb3IgbmV0d29yayBub2RlcyANCiAgIA0KICBFYWNoIG5vZGUgb2YgdGhlIHNl bnNvciBuZXR3b3JrIGlzIHRoZSBzZWxmLWNvbnRhaW5lZCBpbXBsZW1lbnRhdGlvbiANCiAgb2Yg YSBzaW5nbGUgYnVuZGxlIG5vZGUuICBBbGwgZnVuY3Rpb25zIG9mIHRoZSBidW5kbGUgcHJvdG9j b2wgYWdlbnQsIA0KICBhbGwgY29udmVyZ2VuY2UgbGF5ZXIgYWRhcHRlcnMsIGFuZCB0aGUgYWRt aW5pc3RyYXRpdmUgZWxlbWVudCBvZiB0aGUgDQogIGFwcGxpY2F0aW9uIGFnZW50IGFyZSBpbXBs ZW1lbnRlZCBpbiBzaW1wbGlmaWVkIGZvcm0gaW4gQVNJQ3MsIHdoaWxlIA0KICB0aGUgYXBwbGlj YXRpb24tc3BlY2lmaWMgZWxlbWVudCBvZiBlYWNoIG5vZGUncyBhcHBsaWNhdGlvbiBhZ2VudCBp cyANCiAgaW1wbGVtZW50ZWQgaW4gYSBwcm9ncmFtbWFibGUgbWljcm9jb250cm9sbGVyLiAgRm9y d2FyZGluZyBpcyANCiAgcnVkaW1lbnRhcnk6IGFsbCBidW5kbGVzIGFyZSBmb3J3YXJkZWQgb24g YSBoYXJkLWNvZGVkIGRlZmF1bHQgcm91dGUuIA0KICAgDQogIGQpIERlZGljYXRlZCBidW5kbGUg cm91dGVyIA0KICAgDQogIEVhY2ggY29tcHV0ZXIgY29uc3RpdHV0ZXMgYSBzaW5nbGUgYnVuZGxl IG5vZGUgdGhhdCBmdW5jdGlvbnMgc29sZWx5IA0KICBhcyBhIGhpZ2gtcGVyZm9ybWFuY2UgYnVu ZGxlIGZvcndhcmRlci4gIE1hbnkgc3RhbmRhcmQgZnVuY3Rpb25zIG9mIA0KICB0aGUgYnVuZGxl IHByb3RvY29sIGFnZW50LCB0aGUgY29udmVyZ2VuY2UgbGF5ZXIgYWRhcHRlcnMsIGFuZCB0aGUg DQogIGFkbWluaXN0cmF0aXZlIGVsZW1lbnQgb2YgdGhlIGFwcGxpY2F0aW9uIGFnZW50IGFyZSBp bXBsZW1lbnRlZCBpbiANCiAgQVNJQ3MsIGJ1dCBzb21lIGZ1bmN0aW9ucyBhcmUgaW1wbGVtZW50 ZWQgaW4gYSBoaWdoLXNwZWVkIHByb2Nlc3NvciANCiAgdG8gZW5hYmxlIHJlcHJvZ3JhbW1pbmcg YXMgbmVjZXNzYXJ5LiAgVGhlIG5vZGUncyBhcHBsaWNhdGlvbiBhZ2VudCANCiAgaGFzIG5vIGFw cGxpY2F0aW9uLXNwZWNpZmljIGVsZW1lbnQuICBTdWJzdGFudGlhbCBub24tdm9sYXRpbGUgDQog IHN0b3JhZ2UgcmVzb3VyY2VzIGFyZSBwcm92aWRlZCwgYW5kIGFyYml0cmFyaWx5IGNvbXBsZXgg Zm9yd2FyZGluZyANCiAgYWxnb3JpdGhtcyBhcmUgc3VwcG9ydGVkLiAgDQogICANCjIuMyBTZXJ2 aWNlcyBvZmZlcmVkIGJ5IGJ1bmRsZSBwcm90b2NvbCBhZ2VudHMgDQogICANCiAgVGhlIGJ1bmRs ZSBwcm90b2NvbCBhZ2VudCBvZiBlYWNoIG5vZGUgaXMgZXhwZWN0ZWQgdG8gcHJvdmlkZSB0aGUg DQogIGZvbGxvd2luZyBzZXJ2aWNlcyB0byB0aGUgbm9kZSdzIGFwcGxpY2F0aW9uIGFnZW50OiAN CiAgICANCiAgIGEpIGNvbW1lbmNpbmcgYSByZWdpc3RyYXRpb24gKHJlZ2lzdGVyaW5nIGEgbm9k ZSBpbiBhbiBlbmRwb2ludCk7IA0KICAgYikgdGVybWluYXRpbmcgYSByZWdpc3RyYXRpb247IA0K ICAgYykgc3dpdGNoaW5nIGEgcmVnaXN0cmF0aW9uIGJldHdlZW4gQWN0aXZlIGFuZCBQYXNzaXZl IHN0YXRlOyANCiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4cGlyZXMgLSBT ZXB0ZW1iZXIgMjAwNyAgICAgW1BhZ2UgOV0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICBCdW5kbGUg UHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcgDQogDQogDQogICBkKSB0 cmFuc21pdHRpbmcgYSBidW5kbGUgdG8gYW4gaWRlbnRpZmllZCBidW5kbGUgZW5kcG9pbnQ7IA0K ICAgZSkgY2FuY2VsaW5nIGEgdHJhbnNtaXNzaW9uOyANCiAgIGYpIHBvbGxpbmcgYSByZWdpc3Ry YXRpb24gdGhhdCBpcyBpbiBwYXNzaXZlIHN0YXRlOyANCiAgIGcpIGRlbGl2ZXJpbmcgYSByZWNl aXZlZCBidW5kbGUuIA0KICAgDQozLiAgIEJ1bmRsZSBGb3JtYXQgDQogICANCiAgRWFjaCBidW5k bGUgc2hhbGwgYmUgYSBjb25jYXRlbmF0ZWQgc2VxdWVuY2Ugb2YgYXQgbGVhc3QgdHdvIGJsb2Nr IA0KICBzdHJ1Y3R1cmVzLiAgVGhlIGZpcnN0IGJsb2NrIGluIHRoZSBzZXF1ZW5jZSBtdXN0IGJl IGEgcHJpbWFyeSBidW5kbGUgDQogIGJsb2NrLCBhbmQgbm8gYnVuZGxlIG1heSBoYXZlIG1vcmUg dGhhbiBvbmUgcHJpbWFyeSBidW5kbGUgYmxvY2suICANCiAgQWRkaXRpb25hbCBidW5kbGUgcHJv dG9jb2wgYmxvY2tzIG9mIG90aGVyIHR5cGVzIG1heSBmb2xsb3cgdGhlIA0KICBwcmltYXJ5IGJs b2NrIHRvIHN1cHBvcnQgZXh0ZW5zaW9ucyB0byB0aGUgQnVuZGxlIFByb3RvY29sLCBzdWNoIGFz IA0KICB0aGUgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIFs1XS4gIEF0IG1vc3Qgb25lIG9mIHRo ZSBibG9ja3MgaW4gdGhlIA0KICBzZXF1ZW5jZSBtYXkgYmUgYSBwYXlsb2FkIGJsb2NrLiAgVGhl IGxhc3QgYmxvY2sgaW4gdGhlIHNlcXVlbmNlIG11c3QgDQogIGhhdmUgdGhlICJsYXN0IGJsb2Nr IiBmbGFnIChpbiBpdHMgYmxvY2sgcHJvY2Vzc2luZyBjb250cm9sIGZsYWdzKSANCiAgc2V0IHRv IDE7IGZvciBldmVyeSBvdGhlciBibG9jayBpbiB0aGUgYnVuZGxlIGFmdGVyIHRoZSBwcmltYXJ5 IA0KICBibG9jaywgdGhpcyBmbGFnIG11c3QgYmUgc2V0IHRvIHplcm8uIA0KICAgDQozLjEgU2Vs Zi1EZWxpbWl0aW5nIE51bWVyaWMgVmFsdWVzIChTRE5WKSANCiAgIA0KICBUaGUgZGVzaWduIG9m IHRoZSBidW5kbGUgcHJvdG9jb2wgYXR0ZW1wdHMgdG8gcmVjb25jaWxlIG1pbmltYWwgDQogIGNv bnN1bXB0aW9uIG9mIHRyYW5zbWlzc2lvbiBiYW5kd2lkdGggd2l0aDogDQogICBvIGV4dGVuc2li aWxpdHkgdG8gYWRkcmVzcyByZXF1aXJlbWVudHMgbm90IHlldCBpZGVudGlmaWVkLCBhbmQgDQog ICBvIHNjYWxhYmlsaXR5IGFjcm9zcyBhIHdpZGUgcmFuZ2Ugb2YgbmV0d29yayBzY2FsZXMgYW5k IHBheWxvYWQgDQogIHNpemVzLiANCiAgIA0KICBBIGtleSBzdHJhdGVnaWMgZWxlbWVudCBpbiB0 aGUgZGVzaWduIGlzIHRoZSB1c2Ugb2Ygc2VsZi1kZWxpbWl0aW5nIA0KICBudW1lcmljIHZhbHVl cyAoU0ROVnMpLiAgVGhlIFNETlYgZW5jb2Rpbmcgc2NoZW1lIGlzIGNsb3NlbHkgYWRhcHRlZCAN CiAgZnJvbSB0aGUgQWJzdHJhY3QgU3ludGF4IE5vdGF0aW9uIE9uZSBCYXNpYyBFbmNvZGluZyBS dWxlcyBmb3IgDQogIHN1YmlkZW50aWZpZXJzIHdpdGhpbiBhbiAgb2JqZWN0IGlkZW50aWZpZXIg dmFsdWUgWzldLiAgQW4gU0ROViBpcyBhIA0KICBudW1lcmljIHZhbHVlIGVuY29kZWQgaW4gTiBv Y3RldHMsIHRoZSBsYXN0IG9mIHdoaWNoIGhhcyBpdHMgbW9zdCANCiAgc2lnbmlmaWNhbnQgYml0 IChNU0IpIHNldCB0byB6ZXJvOyB0aGUgTVNCIG9mIGV2ZXJ5IG90aGVyIG9jdGV0IGluIA0KICB0 aGUgU0ROViBtdXN0IGJlIHNldCB0byAxLiAgVGhlIHZhbHVlIGVuY29kZWQgaW4gYW4gU0ROViBp cyB0aGUgDQogIHVuc2lnbmVkIGJpbmFyeSBudW1iZXIgb2J0YWluZWQgYnkgY29uY2F0ZW5hdGlu ZyBpbnRvIGEgc2luZ2xlIGJpdCANCiAgc3RyaW5nIHRoZSA3IGxlYXN0IHNpZ25pZmljYW50IGJp dHMgb2YgZWFjaCBvY3RldCBvZiB0aGUgU0ROVi4gDQogICANCiAgVGhlIGZvbGxvd2luZyBleGFt cGxlcyBpbGx1c3RyYXRlIHRoZSBlbmNvZGluZyBzY2hlbWUgZm9yIHZhcmlvdXMgDQogIGhleGFk ZWNpbWFsIHZhbHVlcy4gIA0KICAgDQogIDB4QUJDICA6IDEwMTAgMTAxMSAxMTAwICANCiAgICAg ICAgICAgaXMgZW5jb2RlZCBhcyANCiAgICAgICAgICAgezEgMDAgMTAxMDF9IHswIDAxMTExMDB9 ICANCiAgICAgICAgICAgPSAxMDAxMDEwMSAwMDExMTEwMCANCiAgIA0KICAweDEyMzQgOiAwMDAx IDAwMTAgMDAxMSAwMTAwIA0KICAgICAgICAgPSAgICAxIDAwMTAgMDAxMSAwMTAwICANCiAgICAg ICAgICAgaXMgZW5jb2RlZCBhcyANCiAgICAgICAgICAgezEgMCAxMDAxMDB9IHswIDAxMTAxMDB9 IA0KICAgICAgICAgICA9IDEwMTAwMTAwIDAwMTEwMTAwICAgDQogICAgICAgICAgICANCg0KIA0K IA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJlcyAtIFNlcHRlbWJlciAyMDA3 ICAgIFtQYWdlIDEwXSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1bmRsZSBQcm90b2NvbCBTcGVj aWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCiAgMHg0MjM0IDogMDEwMCAwMDEw IDAwMTEgMDEwMCANCiAgICAgICAgID0gIDEwMCAwMDEwIDAwMTEgMDEwMCAgDQogICAgICAgICAg IGlzIGVuY29kZWQgYXMgDQogICAgICAgICAgIHsxIDAwMDAwMCAxfSB7MSAwMDAwMTAwfSB7MCAw MTEwMTAwfSANCiAgICAgICAgICAgPSAxMDAwMDAwMSAxMDAwMDEwMCAwMDExMDEwMCANCiAgICAg ICAgICAgIA0KICAweDdGICAgOiAwMTExIDExMTEgDQogICAgICAgICA9ICAxMTEgMTExMSAgDQog ICAgICAgICAgIGlzIGVuY29kZWQgYXMgDQogICAgICAgICAgIHswIDExMTExMTF9IA0KICAgICAg ICAgICA9IDAxMTExMTExIA0KICAgDQogIE5vdGU6IENhcmUgbXVzdCBiZSB0YWtlbiB0byBtYWtl IHN1cmUgdGhhdCB0aGUgdmFsdWUgdG8gYmUgZW5jb2RlZCBpcyANCiAgKGluIGNvbmNlcHQpIHBh ZGRlZCB3aXRoIGhpZ2gtb3JkZXIgemVybyBiaXRzIHRvIG1ha2UgaXRzIGJpdHdpc2UgDQogIGxl bmd0aCBhIG11bHRpcGxlIG9mIDcgYmVmb3JlIGVuY29kaW5nLiAgQWxzbyBub3RlIHRoYXQsIHdo aWxlIHRoZXJlIA0KICBpcyBubyB0aGVvcmV0aWNhbCBsaW1pdCBvbiB0aGUgc2l6ZSBvZiBhbiBT RE5WIGZpZWxkLCB0aGUgb3ZlcmhlYWQgb2YgDQogIHRoZSBTRE5WIHNjaGVtZSBpcyAxOjcsIGku ZS4sIG9uZSBiaXQgb2Ygb3ZlcmhlYWQgZm9yIGV2ZXJ5IDcgYml0cyBvZiANCiAgYWN0dWFsIGRh dGEgdG8gYmUgZW5jb2RlZC4gIFRodXMgYSA3LW9jdGV0IHZhbHVlIChhIDU2LWJpdCBxdWFudGl0 eSANCiAgd2l0aCBubyBsZWFkaW5nIHplcm9lcykgd291bGQgYmUgZW5jb2RlZCBpbiBhbiA4LW9j dGV0IFNETlY7IGFuIDgtDQogIG9jdGV0IHZhbHVlIChhIDY0LWJpdCBxdWFudGl0eSB3aXRoIG5v IGxlYWRpbmcgemVyb2VzKSB3b3VsZCBiZSANCiAgZW5jb2RlZCBpbiBhIDEwLW9jdGV0IFNETlYg KG9uZSBvY3RldCBjb250YWluaW5nIHRoZSBoaWdoLW9yZGVyIGJpdCANCiAgb2YgdGhlIHZhbHVl IHBhZGRlZCB3aXRoIHNpeCBsZWFkaW5nIHplcm8gYml0cywgZm9sbG93ZWQgYnkgbmluZSANCiAg b2N0ZXRzIGNvbnRhaW5pbmcgdGhlIHJlbWFpbmluZyA2MyBiaXRzIG9mIHRoZSB2YWx1ZSkuICAx NDggYml0cyBvZiANCiAgb3ZlcmhlYWQgd291bGQgYmUgY29uc3VtZWQgaW4gZW5jb2RpbmcgYSAx MDI0LWJpdCBSU0EgZW5jcnlwdGlvbiBrZXkgDQogIGRpcmVjdGx5IGluIGFuIFNETlYuICBJbiBn ZW5lcmFsLCBhbiBOLWJpdCBxdWFudGl0eSB3aXRoIG5vIGxlYWRpbmcgDQogIHplcm9lcyBpcyBl bmNvZGVkIGluIGFuIFNETlYgb2NjdXB5aW5nIGNlaWwoTi83KSBvY3RldHMsIHdoZXJlIGNlaWwg DQogIGlzIHRoZSBpbnRlZ2VyIGNlaWxpbmcgZnVuY3Rpb24uIA0KICAgDQogIEltcGxlbWVudGF0 aW9ucyBvZiB0aGUgQnVuZGxlIFByb3RvY29sIG1heSBoYW5kbGUgYXMgYW4gaW52YWxpZCANCiAg bnVtZXJpYyB2YWx1ZSBhbnkgU0ROViB0aGF0IGVuY29kZXMgYW4gaW50ZWdlciB0aGF0IGlzIGxh cmdlciB0aGFuIA0KICAoMl42NCAtIDEpLiANCiAgIA0KICBBbiBTRE5WIGNhbiBiZSB1c2VkIHRv IHJlcHJlc2VudCBib3RoIHZlcnkgbGFyZ2UgYW5kIHZlcnkgc21hbGwgDQogIGludGVnZXIgdmFs dWVzLiAgSG93ZXZlciwgU0ROViBpcyBjbGVhcmx5IG5vdCB0aGUgYmVzdCB3YXkgdG8gDQogIHJl cHJlc2VudCBldmVyeSBudW1lcmljIHZhbHVlLiAgRm9yIGV4YW1wbGUsIGFuIFNETlYgaXMgYSBw b29yIHdheSB0byANCiAgcmVwcmVzZW50IGFuIGludGVnZXIgd2hvc2UgdmFsdWUgdHlwaWNhbGx5 IGZhbGxzIGluIHRoZSByYW5nZSAxMjggdG8gDQogIDI1NS4gIEluIGdlbmVyYWwsIHRob3VnaCwg d2UgYmVsaWV2ZSB0aGF0IFNETlYgcmVwcmVzZW50YXRpb24gb2YgDQogIG51bWVyaWMgdmFsdWVz IGluIGJ1bmRsZSBibG9ja3MgeWllbGRzIHRoZSBzbWFsbGVzdCBibG9jayBzaXplcyANCiAgd2l0 aG91dCBzYWNyaWZpY2luZyBzY2FsYWJpbGl0eS4gDQogICANCjMuMiBDYW5vbmljYWwgQnVuZGxl IEJsb2NrIEZvcm1hdCANCiAgIA0KICBFdmVyeSBidW5kbGUgYmxvY2sgb2YgZXZlcnkgdHlwZSBv dGhlciB0aGFuIHRoZSBwcmltYXJ5IGJ1bmRsZSBibG9jayANCiAgY29tcHJpc2VzIHRoZSBmb2xs b3dpbmcgZmllbGRzLCBpbiB0aGlzIG9yZGVyOiANCiAgIG8gQmxvY2sgdHlwZSBjb2RlLCBleHBy ZXNzZWQgYXMgYW4gOC1iaXQgdW5zaWduZWQgYmluYXJ5IGludGVnZXIuICANCiAgQnVuZGxlIGJs b2NrIHR5cGUgY29kZSAxIGluZGljYXRlcyB0aGF0IHRoZSBibG9jayBpcyBhIGJ1bmRsZSBwYXls b2FkIA0KICBibG9jay4gIEJsb2NrIHR5cGUgY29kZXMgMTkyIHRocm91Z2ggMjU1IGFyZSBub3Qg ZGVmaW5lZCBpbiB0aGlzIA0KICBzcGVjaWZpY2F0aW9uIGFuZCBhcmUgYXZhaWxhYmxlIGZvciBw cml2YXRlIGFuZC9vciBleHBlcmltZW50YWwgdXNlLiAgDQogIEFsbCBvdGhlciB2YWx1ZXMgb2Yg dGhlIGJsb2NrIHR5cGUgY29kZSBhcmUgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuIA0KICAgbyBC bG9jayBwcm9jZXNzaW5nIGNvbnRyb2wgZmxhZ3MsIGFuIHVuc2lnbmVkIGludGVnZXIgZXhwcmVz c2VkIGFzIA0KICBhbiBTRE5WLiAgVGhlIGluZGl2aWR1YWwgYml0cyBvZiB0aGlzIGludGVnZXIg YXJlIHVzZWQgdG8gaW52b2tlIA0KIA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAg RXhwaXJlcyAtIFNlcHRlbWJlciAyMDA3ICAgIFtQYWdlIDExXSANCgxJbnRlcm5ldCBEcmFmdCAg ICAgIEJ1bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiAN CiANCiAgc2VsZWN0ZWQgYmxvY2sgcHJvY2Vzc2luZyBjb250cm9sIGZlYXR1cmVzLiAgDQogICBv IEJsb2NrIGRhdGEgbGVuZ3RoLCBhbiB1bnNpZ25lZCBpbnRlZ2VyIGV4cHJlc3NlZCBhcyBhbiBT RE5WLiAgVGhlIA0KICBCbG9jayBkYXRhIGxlbmd0aCBmaWVsZCBjb250YWlucyB0aGUgYWdncmVn YXRlIGxlbmd0aCBvZiBhbGwgDQogIHJlbWFpbmluZyBmaWVsZHMgb2YgdGhlIGJsb2NrLCBpLmUu LCB0aGUgYmxvY2stdHlwZS1zcGVjaWZpYyBkYXRhIA0KICBmaWVsZHMuIA0KICAgbyBCbG9jay10 eXBlLXNwZWNpZmljIGRhdGEgZmllbGRzLCB3aG9zZSBmb3JtYXQgYW5kIG9yZGVyIGFyZSB0eXBl LQ0KICBzcGVjaWZpYyBhbmQgd2hvc2UgYWdncmVnYXRlIGxlbmd0aCBpbiBvY3RldHMgaXMgdGhl IHZhbHVlIG9mIHRoZSANCiAgYmxvY2sgZGF0YSBsZW5ndGggZmllbGQuICBBbGwgbXVsdGktYnl0 ZSBibG9jay10eXBlLXNwZWNpZmljIGRhdGEgDQogIGZpZWxkcyBhcmUgcmVwcmVzZW50ZWQgaW4g bmV0d29yayBieXRlIG9yZGVyLiANCiAgIA0KMy4zIEJ1bmRsZSBQcm9jZXNzaW5nIENvbnRyb2wg RmxhZ3MgDQogICANCiAgVGhlIGJ1bmRsZSBwcm9jZXNzaW5nIGNvbnRyb2wgZmxhZ3MgZmllbGQg aW4gdGhlIHByaW1hcnkgYnVuZGxlIGJsb2NrIA0KICBvZiBlYWNoIGJ1bmRsZSBpcyBhbiBTRE5W OyB0aGUgdmFsdWUgZW5jb2RlZCBpbiB0aGlzIFNETlYgaXMgYSBzdHJpbmcgDQogIG9mIGJpdHMg dXNlZCB0byBpbnZva2Ugc2VsZWN0ZWQgYnVuZGxlIHByb2Nlc3NpbmcgY29udHJvbCBmZWF0dXJl cy4gIA0KICBUaGUgc2lnbmlmaWNhbmNlIG9mIHRoZSB2YWx1ZXMgaW4gYWxsIGN1cnJlbnRseSBk ZWZpbmVkIHBvc2l0aW9ucyBvZiANCiAgdGhpcyBiaXQgc3RyaW5nLCBpbiBvcmRlciBmcm9tIGxl YXN0LXNpZ25pZmljYW50IHBvc2l0aW9uIChsYWJlbGVkIA0KICAnMjAnKSB0byBtb3N0LXNpZ25p ZmljYW50IChsYWJlbGVkICcwJyksIGFyZSBkZXNjcmliZWQgaGVyZS4gIE5vdGUgDQogIHRoYXQg YmVjYXVzZSB0aGUgdmFsdWUgaXMgZW5jb2RlZCBpbiBhbiBTRE5WLCBmdXR1cmUgY2FwYWJpbGl0 aWVzIG1heSANCiAgYmUgZGVmaW5lZCB0aGF0IHdvdWxkIGV4dGVuZCB0aGUgYml0IHN0cmluZyB0 byB0aGUgbGVmdCwgdG8gaW5jbHVkZSANCiAgbW9yZSBzaWduaWZpY2FudCBiaXRzLiANCiAgIA0K ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgDQogICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCANCiAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgfFN0YXR1cyBSZXBvcnR8Q2xhc3Mgb2YgU3Zj LnwgICBHZW5lcmFsICAgfCANCiAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyANCiAgIA0KICBUaGUgYml0cyBpbiBwb3NpdGlvbnMgMjAgdGhyb3VnaCAxNCBhcmUg ZmxhZ3MgdGhhdCBjaGFyYWN0ZXJpemUgdGhlIA0KICBidW5kbGUgYXMgZm9sbG93czogDQogICAN CiAgMjAgLSBCdW5kbGUgaXMgYSBmcmFnbWVudC4gDQogIDE5IC0gQXBwbGljYXRpb24gZGF0YSB1 bml0IGlzIGFuIGFkbWluaXN0cmF0aXZlIHJlY29yZC4gDQogIDE4IC0gQnVuZGxlIG11c3Qgbm90 IGJlIGZyYWdtZW50ZWQuIA0KICAxNyAtIEN1c3RvZHkgdHJhbnNmZXIgaXMgcmVxdWVzdGVkLiAN CiAgMTYgLSBEZXN0aW5hdGlvbiBlbmRwb2ludCBpcyBhIHNpbmdsZXRvbi4gDQogIDE1IC0gQWNr bm93bGVkZ2VtZW50IGJ5IGFwcGxpY2F0aW9uIGlzIHJlcXVlc3RlZC4gDQogIDE0IC0gUmVzZXJ2 ZWQgZm9yIGZ1dHVyZSB1c2UuIA0KICAgDQogIFRoZSBiaXRzIGluIHBvc2l0aW9ucyAxMyB0aHJv dWdoIDcgYXJlIHVzZWQgdG8gaW5kaWNhdGUgdGhlIGJ1bmRsZSdzIA0KICBjbGFzcyBvZiBzZXJ2 aWNlLiAgVGhlIGJpdHMgaW4gcG9zaXRpb25zIDEzIGFuZCAxMiBjb25zdGl0dXRlIGEgdHdvLQ0K ICBiaXQgcHJpb3JpdHkgZmllbGQgaW5kaWNhdGluZyB0aGUgYnVuZGxlJ3MgcHJpb3JpdHksIHdp dGggaGlnaGVyIA0KICB2YWx1ZXMgYmVpbmcgb2YgaGlnaGVyIHByaW9yaXR5OiAwMCA9IGJ1bGss IDAxID0gbm9ybWFsLCAxMCA9IA0KICBleHBlZGl0ZWQsIDExIGlzIHJlc2VydmVkIGZvciBmdXR1 cmUgdXNlLiAgVGhlIGJpdHMgaW4gcG9zaXRpb25zIDExIA0KICB0aHJvdWdoIDcgYXJlIHJlc2Vy dmVkIGZvciBmdXR1cmUgdXNlLiANCiAgIA0KICBUaGUgYml0cyBpbiBwb3NpdGlvbnMgNiB0aHJv dWdoIDAgYXJlIHN0YXR1cyByZXBvcnQgcmVxdWVzdCBmbGFncy4gIA0KICBUaGVzZSBmbGFncyBh cmUgdXNlZCB0byByZXF1ZXN0IHN0YXR1cyByZXBvcnRzIGFzIGZvbGxvd3M6IA0KICAgDQogIDYg DSAgIC0gUmVxdWVzdCByZXBvcnRpbmcgb2YgYnVuZGxlIHJlY2VwdGlvbi4gDQogIDUgDSAgIC0g UmVxdWVzdCByZXBvcnRpbmcgb2YgY3VzdG9keSBhY2NlcHRhbmNlLiANCiANCiANCksuIFNjb3R0 IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwNyAgICBbUGFnZSAx Ml0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICBCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAg ICAgICAgIE1hcmNoIDIwMDcgDQogDQogDQogIDQgDSAgIC0gUmVxdWVzdCByZXBvcnRpbmcgb2Yg YnVuZGxlIGZvcndhcmRpbmcuIA0KICAzIA0gICAtIFJlcXVlc3QgcmVwb3J0aW5nIG9mIGJ1bmRs ZSBkZWxpdmVyeS4gDQogIDIgDSAgIC0gUmVxdWVzdCByZXBvcnRpbmcgb2YgYnVuZGxlIGRlbGV0 aW9uLiANCiAgMSANICAgLSBSZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4gDQogIDAgDSAgIC0gUmVz ZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuIA0KICAgDQogIElmIHRoZSBidW5kbGUgcHJvY2Vzc2luZyBj b250cm9sIGZsYWdzIGluZGljYXRlIHRoYXQgdGhlIGJ1bmRsZSdzIA0KICBhcHBsaWNhdGlvbiBk YXRhIHVuaXQgaXMgYW4gYWRtaW5pc3RyYXRpdmUgcmVjb3JkLCB0aGVuIHRoZSBjdXN0b2R5IA0K ICB0cmFuc2ZlciByZXF1ZXN0ZWQgZmxhZyBtdXN0IGJlIHplcm8gYW5kIGFsbCBzdGF0dXMgcmVw b3J0IHJlcXVlc3QgDQogIGZsYWdzIG11c3QgYmUgemVyby4gIElmIHRoZSBjdXN0b2R5IHRyYW5z ZmVyIHJlcXVlc3RlZCBmbGFnIGlzIDEgdGhlbiANCiAgdGhlIHNlbmRpbmcgbm9kZSByZXF1ZXN0 cyB0aGF0IHRoZSByZWNlaXZpbmcgbm9kZSBhY2NlcHQgY3VzdG9keSBvZiANCiAgdGhlIGJ1bmRs ZS4gIElmIHRoZSBidW5kbGUncyBzb3VyY2UgZW5kcG9pbnQgSUQgaXMgImR0bjpub25lIiAoc2Vl IA0KICBiZWxvdyksIHRoZW4gdGhlIGJ1bmRsZSBpcyBub3QgdW5pcXVlbHkgaWRlbnRpZmlhYmxl IGFuZCBhbGwgYnVuZGxlIA0KICBwcm90b2NvbCBmZWF0dXJlcyB0aGF0IHJlbHkgb24gYnVuZGxl IGlkZW50aXR5IG11c3QgdGhlcmVmb3JlIGJlIA0KICBkaXNhYmxlZDogdGhlIGJ1bmRsZSdzIGN1 c3RvZHkgdHJhbnNmZXIgcmVxdWVzdGVkIGZsYWcgbXVzdCBiZSB6ZXJvLCANCiAgdGhlICJidW5k bGUgbXVzdCBub3QgYmUgZnJhZ21lbnRlZCIgZmxhZyBtdXN0IGJlIDEsIGFuZCBhbGwgc3RhdHVz IA0KICByZXBvcnQgcmVxdWVzdCBmbGFncyBtdXN0IGJlIHplcm8uICANCiAgIA0KMy40IEJsb2Nr IFByb2Nlc3NpbmcgQ29udHJvbCBGbGFncyANCiAgIA0KICBUaGUgYmxvY2sgcHJvY2Vzc2luZyBj b250cm9sIGZsYWdzIGZpZWxkIGluIGV2ZXJ5IGJsb2NrIG90aGVyIHRoYW4gDQogIHRoZSBwcmlt YXJ5IGJ1bmRsZSBibG9jayBpcyBhbiBTRE5WOyB0aGUgdmFsdWUgZW5jb2RlZCBpbiB0aGlzIFNE TlYgDQogIGlzIGEgc3RyaW5nIG9mIGJpdHMgdXNlZCB0byBpbnZva2Ugc2VsZWN0ZWQgYmxvY2sg cHJvY2Vzc2luZyBjb250cm9sIA0KICBmZWF0dXJlcy4gIFRoZSBzaWduaWZpY2FuY2Ugb2YgdGhl IHZhbHVlcyBpbiBhbGwgY3VycmVudGx5IGRlZmluZWQgDQogIHBvc2l0aW9ucyBvZiB0aGlzIGJp dCBzdHJpbmcsIGluIG9yZGVyIGZyb20gbGVhc3Qtc2lnbmlmaWNhbnQgDQogIHBvc2l0aW9uIChs YWJlbGVkICc2JykgdG8gbW9zdC1zaWduaWZpY2FudCAobGFiZWxlZCAnMCcpLCBhcmUgDQogIGRl c2NyaWJlZCBoZXJlLiANCiAgIA0KICA2IA0gICAtIEJsb2NrIG11c3QgYmUgcmVwbGljYXRlZCBp biBldmVyeSBmcmFnbWVudC4gDQogIDUgDSAgIC0gVHJhbnNtaXQgc3RhdHVzIHJlcG9ydCBpZiBi bG9jayBjYW4ndCBiZSBwcm9jZXNzZWQuIA0KICA0IA0gICAtIERlbGV0ZSBidW5kbGUgaWYgYmxv Y2sgY2FuJ3QgYmUgcHJvY2Vzc2VkLiANCiAgMyANICAgLSBMYXN0IGJsb2NrLiANCiAgMiANICAg LSBEaXNjYXJkIGJsb2NrIGlmIGl0IGNhbid0IGJlIHByb2Nlc3NlZC4gDQogIDEgDSAgIC0gQmxv Y2sgd2FzIGZvcndhcmRlZCB3aXRob3V0IGJlaW5nIHByb2Nlc3NlZC4gDQogIDAgDSAgIC0gUmVz ZXJ2ZWQgZm9yIGJ1bmRsZSBzZWN1cml0eSBwcm90b2NvbCB1c2UuIA0KICAgDQogIEZvciBlYWNo IGJ1bmRsZSB3aG9zZSBwcmltYXJ5IGJsb2NrJ3MgYnVuZGxlIHByb2Nlc3NpbmcgY29udHJvbCBm bGFncyANCiAgKHNlZSBhYm92ZSkgaW5kaWNhdGUgdGhhdCB0aGUgYnVuZGxlJ3MgYXBwbGljYXRp b24gZGF0YSB1bml0IGlzIGFuIA0KICBhZG1pbmlzdHJhdGl2ZSByZWNvcmQsIHRoZSAiVHJhbnNt aXQgc3RhdHVzIHJlcG9ydCBpZiBibG9jayBjYW4ndCBiZSANCiAgcHJvY2Vzc2VkIiBmbGFnIGlu IHRoZSBibG9jayBwcm9jZXNzaW5nIGZsYWdzIGZpZWxkIG9mIGV2ZXJ5IG90aGVyIA0KICBibG9j ayBpbiB0aGUgYnVuZGxlIG11c3QgYmUgemVyby4gDQogICANCjMuNSBFbmRwb2ludCBJRHMgDQog ICANCiAgVGhlIGRlc3RpbmF0aW9ucyBvZiBidW5kbGVzIGFyZSBidW5kbGUgZW5kcG9pbnRzLCBp ZGVudGlmaWVkIGJ5IHRleHQgDQogIHN0cmluZ3MgdGVybWVkICJlbmRwb2ludCBJRHMiIChzZWUg c2VjdGlvbiAyLjEpLiAgRWFjaCBlbmRwb2ludCBJRCANCiAgY29udmV5ZWQgaW4gYW55IGJ1bmRs ZSBibG9jayB0YWtlcyB0aGUgZm9ybSBvZiBhIFVuaWZvcm0gUmVzb3VyY2UgDQogIElkZW50aWZp ZXIgKFVSSTsgW1JGQzM5ODZdKS4gIEFzIHN1Y2gsIGVhY2ggZW5kcG9pbnQgSUQgY2FuIGJlIA0K ICBjaGFyYWN0ZXJpemVkIGFzIGhhdmluZyB0aGlzIGdlbmVyYWwgc3RydWN0dXJlOiANCiAgIA0K ICAgICAgIDxzY2hlbWUgbmFtZT46PHNjaGVtZS1zcGVjaWZpYyBwYXJ0LCBvciAiU1NQIj4gDQog DQogDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAgICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIw MDcgICAgW1BhZ2UgMTNdIA0KDEludGVybmV0IERyYWZ0ICAgICAgQnVuZGxlIFByb3RvY29sIFNw ZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0KIA0KIA0KICAgDQogIEFzIHVzZWQgZm9y IHRoZSBwdXJwb3NlcyBvZiB0aGUgYnVuZGxlIHByb3RvY29sLCBuZWl0aGVyIHRoZSBsZW5ndGgg DQogIG9mIGEgc2NoZW1lIG5hbWUgbm9yIHRoZSBsZW5ndGggb2YgYW4gU1NQIG1heSBleGNlZWQg MTAyMyBieXRlcy4gDQogICANCiAgQnVuZGxlIGJsb2NrcyBjaXRlIGEgbnVtYmVyIG9mIGVuZHBv aW50IElEcyBmb3IgdmFyaW91cyBwdXJwb3NlcyBvZiANCiAgdGhlIGJ1bmRsZSBwcm90b2NvbC4g IE1hbnksIHRob3VnaCBub3QgbmVjZXNzYXJpbHkgYWxsLCBvZiB0aGUgDQogIGVuZHBvaW50IElE cyByZWZlcnJlZCB0byBpbiB0aGUgYmxvY2tzIG9mIGEgZ2l2ZW4gYnVuZGxlIGFyZSBjb252ZXll ZCANCiAgaW4gdGhlICJkaWN0aW9uYXJ5IiBieXRlIGFycmF5IGluIHRoZSBidW5kbGUncyBwcmlt YXJ5IGJsb2NrLiAgVGhpcyANCiAgYXJyYXkgaXMgc2ltcGx5IHRoZSBjb25jYXRlbmF0aW9uIG9m IGFueSBudW1iZXIgb2YgbnVsbC10ZXJtaW5hdGVkIA0KICBzY2hlbWUgbmFtZXMgYW5kIFNTUHMu IA0KICAgDQogICJFbmRwb2ludCBJRCByZWZlcmVuY2VzIiBhcmUgdXNlZCB0byBjaXRlIGVuZHBv aW50IElEcyB0aGF0IGFyZSANCiAgY29udGFpbmVkIGluIHRoZSBkaWN0aW9uYXJ5OyBhbGwgZW5k cG9pbnQgSUQgY2l0YXRpb25zIGluIHRoZSBwcmltYXJ5IA0KICBidW5kbGUgYmxvY2sgYXJlIGVu ZHBvaW50IElEIHJlZmVyZW5jZXMsIGFuZCBvdGhlciBidW5kbGUgYmxvY2tzIG1heSANCiAgY29u dGFpbiBlbmRwb2ludCBJRCByZWZlcmVuY2VzIGFzIHdlbGwuICBFYWNoIGVuZHBvaW50IElEIHJl ZmVyZW5jZSANCiAgaXMgYW4gb3JkZXJlZCBwYWlyIG9mIDE2LWJpdCB1bnNpZ25lZCBpbnRlZ2Vy czogDQogICAgDQogICBvIFRoZSBvZmZzZXQsIHdpdGhpbiB0aGUgZGljdGlvbmFyeSwgb2YgdGhl IGZpcnN0IGNoYXJhY3RlciBvZiB0aGUgDQogIHJlZmVyZW5jZWQgZW5kcG9pbnQgSUQncyBzY2hl bWUgbmFtZS4gDQogICANCiAgIG8gVGhlIG9mZnNldCwgd2l0aGluIHRoZSBkaWN0aW9uYXJ5LCBv ZiB0aGUgZmlyc3QgY2hhcmFjdGVyIG9mIHRoZSANCiAgcmVmZXJlbmNlZCBlbmRwb2ludCBJRCdz IFNTUC4gDQogICANCiAgVGhpcyBlbmNvZGluZyBlbmFibGVzIGEgZGVncmVlIG9mIGJsb2NrIGNv bXByZXNzaW9uOiB3aGVuIHRoZSBzb3VyY2UgDQogIGFuZCByZXBvcnQtdG8gb2YgYSBidW5kbGUg YXJlIHRoZSBzYW1lIGVuZHBvaW50LCBmb3IgZXhhbXBsZSwgdGhlIA0KICB0ZXh0IG9mIHRoYXQg ZW5kcG9pbnQncyBJRCBtYXkgYmUgY2l0ZWQgdHdpY2UgeWV0IGFwcGVhciBvbmx5IG9uY2UgaW4g DQogIHRoZSBkaWN0aW9uYXJ5LiANCiAgIA0KICBUaGUgc2NoZW1lIGlkZW50aWZpZWQgYnkgdGhl IDxzY2hlbWUgbmFtZT4gaW4gYW4gZW5kcG9pbnQgSUQgaXMgYSBzZXQgDQogIG9mIHN5bnRhY3Rp YyBhbmQgc2VtYW50aWMgcnVsZXMgdGhhdCBmdWxseSBleHBsYWluIGhvdyB0byBwYXJzZSBhbmQg DQogIGludGVycHJldCB0aGUgU1NQLiAgVGhlIHNldCBvZiBhbGxvd2FibGUgc2NoZW1lcyBpcyBl ZmZlY3RpdmVseSANCiAgdW5saW1pdGVkLiAgQW55IHNjaGVtZSBjb25mb3JtaW5nIHRvIFtSRkMy NzE3XSBtYXkgYmUgdXNlZCBpbiBhIA0KICBidW5kbGUgcHJvdG9jb2wgZW5kcG9pbnQgSUQuICBJ biBhZGRpdGlvbiwgYSBzaW5nbGUgYWRkaXRpb25hbCBzY2hlbWUgDQogIGlzIGRlZmluZWQgYnkg dGhlIHByZXNlbnQgZG9jdW1lbnQ6IA0KICAgDQogICBvIFRoZSAiZHRuIiBzY2hlbWUsIHdoaWNo IGlzIHVzZWQgYXQgbWluaW11bSBpbiB0aGUgcmVwcmVzZW50YXRpb24gDQogIG9mIHRoZSBudWxs IGVuZHBvaW50IElEICJkdG46bm9uZSIuICBUaGUgZm9yd2FyZGluZyBvZiBhIGJ1bmRsZSB0byAN CiAgdGhlIG51bGwgZW5kcG9pbnQgaXMgbmV2ZXIgY29udHJhaW5kaWNhdGVkLCBhbmQgdGhlIG1p bmltdW0gcmVjZXB0aW9uIA0KICBncm91cCBmb3IgdGhlIG51bGwgZW5kcG9pbnQgaXMgdGhlIGVt cHR5IHNldC4gDQogICANCiAgTm90ZSB0aGF0LCBhbHRob3VnaCB0aGUgZW5kcG9pbnQgSURzIGNv bnZleWVkIGluIGJ1bmRsZSBibG9ja3MgYXJlIA0KICBleHByZXNzZWQgYXMgVVJJcywgaW1wbGVt ZW50YXRpb25zIG9mIHRoZSBCUCBzZXJ2aWNlIGludGVyZmFjZSBtYXkgDQogIHN1cHBvcnQgZXhw cmVzc2lvbiBvZiBlbmRwb2ludCBJRHMgaW4gc29tZSBpbnRlcm5hdGlvbmFsaXplZCBtYW5uZXIg DQogIChlLmcuLCBJUklzOyBzZWUgUkZDIDM5ODcpLiANCiAgIA0KMy42IEZvcm1hdHMgb2YgQnVu ZGxlIEJsb2NrcyANCiAgIA0KICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBmb3JtYXRzIG9m IHRoZSBwcmltYXJ5IGJsb2NrIGFuZCBwYXlsb2FkIA0KICBibG9jay4gIFJ1bGVzIGZvciBwcm9j ZXNzaW5nIHRoZXNlIGJsb2NrcyBhcHBlYXIgaW4gc2VjdGlvbiA0IG9mIHRoaXMgDQogIGRvY3Vt ZW50LiANCiAgIA0KIA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJlcyAt IFNlcHRlbWJlciAyMDA3ICAgIFtQYWdlIDE0XSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1bmRs ZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCiAgTm90 ZSB0aGF0IHN1cHBsZW1lbnRhcnkgRFROIHByb3RvY29sIHNwZWNpZmljYXRpb25zIChpbmNsdWRp bmcsIGJ1dCANCiAgbm90IHJlc3RyaWN0ZWQgdG8sIHRoZSBCdW5kbGUgU2VjdXJpdHkgUHJvdG9j b2wgWzVdKSBtYXkgcmVxdWlyZSB0aGF0IA0KICBCUCBpbXBsZW1lbnRhdGlvbnMgY29uZm9ybWlu ZyB0byB0aG9zZSBwcm90b2NvbHMgY29uc3RydWN0IGFuZCANCiAgcHJvY2VzcyBhZGRpdGlvbmFs IGJsb2Nrcy4gDQogICANCiAgVGhlIGZvcm1hdCBvZiB0aGUgdHdvIGJhc2ljIEJQIGJsb2NrcyBp cyBzaG93biBpbiBGaWd1cmUgMiBiZWxvdy4gDQogICANCiAgUHJpbWFyeSBCdW5kbGUgQmxvY2sg DQogICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tKyANCiAgfCAgICBWZXJzaW9uICAgICB8ICAgICAgICAgICAgICAgICAg UHJvYy4gRmxhZ3MgKCopICAgICAgICAgICAgICAgICB8IA0KICArLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsgDQogIHwg ICAgICAgICAgICAgICAgICAgICAgICAgIEJsb2NrIGxlbmd0aCAoKikgICAgICAgICAgICAgICAg ICAgICAgICAgfCANCiAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICB8ICAgRGVzdGluYXRpb24gc2NoZW1lIG9m ZnNldCAoKikgfCAgICAgRGVzdGluYXRpb24gU1NQIG9mZnNldCAoKikgIHwgDQogICstLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tKyANCiAgfCAgICAgIFNvdXJjZSBzY2hlbWUgb2Zmc2V0ICgqKSAgIHwgICAgICAgIFNvdXJj ZSBTU1Agb2Zmc2V0ICgqKSAgICB8IA0KICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsgDQogIHwgICAgUmVwb3J0LXRv IHNjaGVtZSBvZmZzZXQgKCopICB8ICAgICAgUmVwb3J0LXRvIFNTUCBvZmZzZXQgKCopICAgfCAN CiAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0rIA0KICB8ICAgIEN1c3RvZGlhbiBzY2hlbWUgb2Zmc2V0ICgqKSAgfCAg ICAgIEN1c3RvZGlhbiBTU1Agb2Zmc2V0ICgqKSAgIHwgDQogICstLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKyANCiAgfCAg ICAgICAgICAgICAgICAgICAgQ3JlYXRpb24gVGltZXN0YW1wIHRpbWUgKCopICAgICAgICAgICAg ICAgICAgICB8IA0KICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogIHwgICAgICAgICAgICAgQ3JlYXRpb24gVGlt ZXN0YW1wIHNlcXVlbmNlIG51bWJlciAoKikgICAgICAgICAgICAgICAgfCANCiAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rIA0KICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgTGlmZXRpbWUgKCopICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgDQogICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKyANCiAgfCAgICAgICAgICAgICAg ICAgICAgICAgIERpY3Rpb25hcnkgbGVuZ3RoICgqKSAgICAgICAgICAgICAgICAgICAgICB8IA0K ICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLSsgDQogIHwgICAgICAgICAgICAgICAgICBEaWN0aW9uYXJ5IGJ5dGUgYXJy YXkgKHZhcmlhYmxlKSAgICAgICAgICAgICAgICAgfCANCiAgKy0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICB8ICAg ICAgICAgICAgICAgICAgICAgIFtGcmFnbWVudCBvZmZzZXQgKCopXSAgICAgICAgICAgICAgICAg ICAgICAgIHwgDQogICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgfCAgICAgICAgICAgICAgW1RvdGFsIGFwcGxp Y2F0aW9uIGRhdGEgdW5pdCBsZW5ndGggKCopXSAgICAgICAgICAgICB8IA0KICArLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsgDQogICANCiAgIA0KICBCdW5kbGUgUGF5bG9hZCBCbG9jayANCiAgKy0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0K ICB8ICBCbG9jayB0eXBlICAgIHwgUHJvYy4gRmxhZ3MgKCopfCAgICAgICAgQmxvY2sgbGVuZ3Ro KCopICAgICAgICAgIHwgDQogICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKyANCiAgLyAgICAgICAgICAgICAgICAgICAg IEJ1bmRsZSBQYXlsb2FkICh2YXJpYWJsZSkgICAgICAgICAgICAgICAgICAgICAvIA0KICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsgDQogICANCiAgICAgICAgICAgICAgICBGaWd1cmUgMjogICBCdW5kbGUgYmxvY2sg Zm9ybWF0cy4gDQogICgqKSBOb3RlczogDQogICANCiAgVGhlIGJ1bmRsZSBwcm9jZXNzaW5nIGNv bnRyb2wgKCJQcm9jLiIpIGZsYWdzIGZpZWxkIGluIHRoZSBQcmltYXJ5IA0KICBCdW5kbGUgQmxv Y2sgaXMgYW4gU0ROViBhbmQgaXMgdGhlcmVmb3JlIHZhcmlhYmxlLWxlbmd0aC4gIEEgdGhyZWUt DQogIG9jdGV0IFNETlYgaXMgc2hvd24gaGVyZSBmb3IgY29udmVuaWVuY2UgaW4gcmVwcmVzZW50 YXRpb24uIA0KICAgDQogDQogDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAgICBFeHBpcmVz IC0gU2VwdGVtYmVyIDIwMDcgICAgW1BhZ2UgMTVdIA0KDEludGVybmV0IERyYWZ0ICAgICAgQnVu ZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0KIA0KIA0KICBU aGUgYmxvY2sgbGVuZ3RoIGZpZWxkIG9mIHRoZSBQcmltYXJ5IEJ1bmRsZSBCbG9jayBpcyBhbiBT RE5WIGFuZCBpcyANCiAgdGhlcmVmb3JlIHZhcmlhYmxlLWxlbmd0aC4gIEEgZm91ci1vY3RldCBT RE5WIGlzIHNob3duIGhlcmUgZm9yIA0KICBjb252ZW5pZW5jZSBpbiByZXByZXNlbnRhdGlvbi4g DQogICANCiAgRWFjaCBvZiB0aGUgZWlnaHQgb2Zmc2V0IGZpZWxkcyBpbiB0aGUgUHJpbWFyeSBC dW5kbGUgQmxvY2sgaXMgYW4gDQogIFNETlYgYW5kIGlzIHRoZXJlZm9yZSB2YXJpYWJsZS1sZW5n dGguICBUd28tb2N0ZXQgU0ROVnMgYXJlIHNob3duIA0KICBoZXJlIGZvciBjb252ZW5pZW5jZSBp biByZXByZXNlbnRhdGlvbi4gDQogICANCiAgVGhlIENyZWF0aW9uIFRpbWVzdGFtcCB0aW1lIGZp ZWxkIGluIHRoZSBQcmltYXJ5IEJ1bmRsZSBCbG9jayBpcyBhbiANCiAgU0ROViBhbmQgaXMgdGhl cmVmb3JlIHZhcmlhYmxlLWxlbmd0aC4gIEEgZm91ci1vY3RldCBTRE5WIGlzIHNob3duIA0KICBo ZXJlIGZvciBjb252ZW5pZW5jZSBpbiByZXByZXNlbnRhdGlvbi4gDQogICANCiAgVGhlIENyZWF0 aW9uIFRpbWVzdGFtcCBzZXF1ZW5jZSBudW1iZXIgZmllbGQgaW4gdGhlIFByaW1hcnkgQnVuZGxl IA0KICBCbG9jayBpcyBhbiBTRE5WIGFuZCBpcyB0aGVyZWZvcmUgdmFyaWFibGUtbGVuZ3RoLiAg QSBmb3VyLW9jdGV0IFNETlYgDQogIGlzIHNob3duIGhlcmUgZm9yIGNvbnZlbmllbmNlIGluIHJl cHJlc2VudGF0aW9uLiANCiAgIA0KICBUaGUgTGlmZXRpbWUgZmllbGQgaW4gdGhlIFByaW1hcnkg QnVuZGxlIEJsb2NrIGlzIGFuIFNETlYgYW5kIGlzIA0KICB0aGVyZWZvcmUgdmFyaWFibGUtbGVu Z3RoLiAgQSBmb3VyLW9jdGV0IFNETlYgaXMgc2hvd24gaGVyZSBmb3IgDQogIGNvbnZlbmllbmNl IGluIHJlcHJlc2VudGF0aW9uLiANCiAgIA0KICBUaGUgZGljdGlvbmFyeSBsZW5ndGggZmllbGQg b2YgdGhlIFByaW1hcnkgQnVuZGxlIEJsb2NrIGlzIGFuIFNETlYgDQogIGFuZCBpcyB0aGVyZWZv cmUgdmFyaWFibGUtbGVuZ3RoLiAgQSBmb3VyLW9jdGV0IFNETlYgaXMgc2hvd24gaGVyZSANCiAg Zm9yIGNvbnZlbmllbmNlIGluIHJlcHJlc2VudGF0aW9uLiANCiAgIA0KICBUaGUgZnJhZ21lbnQg b2Zmc2V0IGZpZWxkIG9mIHRoZSBQcmltYXJ5IEJ1bmRsZSBCbG9jayBpcyBwcmVzZW50IG9ubHkg DQogIGlmIHRoZSBGcmFnbWVudCBmbGFnIGluIHRoZSBibG9jaydzIHByb2Nlc3NpbmcgZmxhZ3Mg Ynl0ZSBpcyBzZXQgdG8gDQogIDEuICBJdCBpcyBhbiBTRE5WIGFuZCBpcyB0aGVyZWZvcmUgdmFy aWFibGUtbGVuZ3RoOyBhIGZvdXItb2N0ZXQgU0ROViANCiAgaXMgc2hvd24gaGVyZSBmb3IgY29u dmVuaWVuY2UgaW4gcmVwcmVzZW50YXRpb24uIA0KICAgDQogIFRoZSB0b3RhbCBhcHBsaWNhdGlv biBkYXRhIHVuaXQgbGVuZ3RoIGZpZWxkIG9mIHRoZSBQcmltYXJ5IEJ1bmRsZSANCiAgQmxvY2sg aXMgcHJlc2VudCBvbmx5IGlmIHRoZSBGcmFnbWVudCBmbGFnIGluIHRoZSBibG9jaydzIHByb2Nl c3NpbmcgDQogIGZsYWdzIGJ5dGUgaXMgc2V0IHRvIDEuICBJdCBpcyBhbiBTRE5WIGFuZCBpcyB0 aGVyZWZvcmUgdmFyaWFibGUtDQogIGxlbmd0aDsgYSBmb3VyLW9jdGV0IFNETlYgaXMgc2hvd24g aGVyZSBmb3IgY29udmVuaWVuY2UgaW4gDQogIHJlcHJlc2VudGF0aW9uLiANCiAgIA0KICBUaGUg YmxvY2sgcHJvY2Vzc2luZyBjb250cm9sICgiUHJvYy4iKSBmbGFncyBmaWVsZCBvZiB0aGUgUGF5 bG9hZCANCiAgQmxvY2sgaXMgYW4gU0ROViBhbmQgaXMgdGhlcmVmb3JlIHZhcmlhYmxlLWxlbmd0 aC4gIEEgb25lLW9jdGV0IFNETlYgDQogIGlzIHNob3duIGhlcmUgZm9yIGNvbnZlbmllbmNlIGlu IHJlcHJlc2VudGF0aW9uLiAgDQogICANCiAgVGhlIGJsb2NrIGxlbmd0aCBmaWVsZCBvZiB0aGUg UGF5bG9hZCBCbG9jayBpcyBhbiBTRE5WIGFuZCBpcyANCiAgdGhlcmVmb3JlIHZhcmlhYmxlLWxl bmd0aC4gIEEgdHdvLW9jdGV0IFNETlYgaXMgc2hvd24gaGVyZSBmb3IgDQogIGNvbnZlbmllbmNl IGluIHJlcHJlc2VudGF0aW9uLiANCiAgIA0KMy42LjEgUHJpbWFyeSBCdW5kbGUgQmxvY2sgDQog ICANCiAgVGhlIHByaW1hcnkgYnVuZGxlIGJsb2NrIGNvbnRhaW5zIHRoZSBiYXNpYyBpbmZvcm1h dGlvbiBuZWVkZWQgdG8gDQogIHJvdXRlIGJ1bmRsZXMgdG8gdGhlaXIgZGVzdGluYXRpb25zLiAg VGhlIGZpZWxkcyBvZiB0aGUgcHJpbWFyeSANCiAgYnVuZGxlIGJsb2NrIGFyZTogDQogICANCiAg IFZlcnNpb24uICBBIDEtYnl0ZSBmaWVsZCBpbmRpY2F0aW5nIHRoZSB2ZXJzaW9uIG9mIHRoZSBi dW5kbGUgDQogICAgICAgICAgcHJvdG9jb2wgdGhhdCBjb25zdHJ1Y3RlZCB0aGlzIGJsb2NrLiAg VGhlIHByZXNlbnQgZG9jdW1lbnQgDQogDQogDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAg ICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDcgICAgW1BhZ2UgMTZdIA0KDEludGVybmV0IERyYWZ0 ICAgICAgQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0K IA0KIA0KICAgICAgICAgIGRlc2NyaWJlcyB2ZXJzaW9uIDB4MDUgb2YgdGhlIGJ1bmRsZSBwcm90 b2NvbC4gDQogICAgDQogICBCdW5kbGUgUHJvY2Vzc2luZyBDb250cm9sIEZsYWdzLiAgVGhlIEJ1 bmRsZSBQcm9jZXNzaW5nIENvbnRyb2wgRmxhZ3MgDQogICAgICAgICAgZmllbGQgaXMgYW4gU0RO ViB0aGF0IGNvbnRhaW5zIHRoZSBidW5kbGUgcHJvY2Vzc2luZyBjb250cm9sIA0KICAgICAgICAg IGZsYWdzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDMuMyBhYm92ZS4gDQogICAgDQogICBCbG9jayBM ZW5ndGguICBUaGUgQmxvY2sgTGVuZ3RoIGZpZWxkIGlzIGFuIFNETlYgdGhhdCBjb250YWlucyB0 aGUgDQogICAgICAgICAgYWdncmVnYXRlIGxlbmd0aCBvZiBhbGwgcmVtYWluaW5nIGZpZWxkcyBv ZiB0aGUgYmxvY2suIA0KICAgIA0KICAgRGVzdGluYXRpb24gU2NoZW1lIE9mZnNldC4gIFRoZSBE ZXN0aW5hdGlvbiBTY2hlbWUgT2Zmc2V0IGZpZWxkIA0KICAgICAgICAgIGNvbnRhaW5zIHRoZSBv ZmZzZXQgd2l0aGluIHRoZSBkaWN0aW9uYXJ5IGJ5dGUgYXJyYXkgb2YgdGhlIA0KICAgICAgICAg IHNjaGVtZSBuYW1lIG9mIHRoZSBlbmRwb2ludCBJRCBvZiB0aGUgYnVuZGxlJ3MgZGVzdGluYXRp b24sIA0KICAgICAgICAgIGkuZS4sIHRoZSBlbmRwb2ludCBjb250YWluaW5nIHRoZSBub2RlKHMp IGF0IHdoaWNoIHRoZSBidW5kbGUgDQogICAgICAgICAgaXMgdG8gYmUgZGVsaXZlcmVkLiANCiAg ICANCiAgIERlc3RpbmF0aW9uIFNTUCBPZmZzZXQuICBUaGUgRGVzdGluYXRpb24gU1NQIE9mZnNl dCBmaWVsZCBjb250YWlucyANCiAgICAgICAgICB0aGUgb2Zmc2V0IHdpdGhpbiB0aGUgZGljdGlv bmFyeSBieXRlIGFycmF5IG9mIHRoZSBzY2hlbWUtDQogICAgICAgICAgc3BlY2lmaWMgcGFydCBv ZiB0aGUgZW5kcG9pbnQgSUQgb2YgdGhlIGJ1bmRsZSdzIGRlc3RpbmF0aW9uLiANCiAgICANCiAg IFNvdXJjZSBTY2hlbWUgT2Zmc2V0LiAgVGhlIFNvdXJjZSBTY2hlbWUgT2Zmc2V0IGZpZWxkIGNv bnRhaW5zIHRoZSANCiAgICAgICAgICBvZmZzZXQgd2l0aGluIHRoZSBkaWN0aW9uYXJ5IGJ5dGUg YXJyYXkgb2YgdGhlIHNjaGVtZSBuYW1lIG9mIA0KICAgICAgICAgIHRoZSBlbmRwb2ludCBJRCBv ZiB0aGUgYnVuZGxlJ3Mgbm9taW5hbCBzb3VyY2UsIGkuZS4sIHRoZSANCiAgICAgICAgICBlbmRw b2ludCBub21pbmFsbHkgY29udGFpbmluZyB0aGUgbm9kZSBmcm9tIHdoaWNoIHRoZSBidW5kbGUg DQogICAgICAgICAgd2FzIGluaXRpYWxseSB0cmFuc21pdHRlZC4gDQogICAgDQogICBTb3VyY2Ug U1NQIE9mZnNldC4gIFRoZSBTb3VyY2UgU1NQIE9mZnNldCBmaWVsZCBjb250YWlucyB0aGUgb2Zm c2V0IA0KICAgICAgICAgIHdpdGhpbiB0aGUgZGljdGlvbmFyeSBieXRlIGFycmF5IG9mIHRoZSBz Y2hlbWUtc3BlY2lmaWMgcGFydCANCiAgICAgICAgICBvZiB0aGUgZW5kcG9pbnQgSUQgb2YgdGhl IGJ1bmRsZSdzIG5vbWluYWwgc291cmNlLiANCiAgICANCiAgIFJlcG9ydC10byBTY2hlbWUgT2Zm c2V0LiAgVGhlIFJlcG9ydC10byBTY2hlbWUgT2Zmc2V0IGZpZWxkIGNvbnRhaW5zIA0KICAgICAg ICAgIHRoZSBvZmZzZXQgd2l0aGluIHRoZSBkaWN0aW9uYXJ5IGJ5dGUgYXJyYXkgb2YgdGhlIHNj aGVtZSBuYW1lIA0KICAgICAgICAgIG9mIHRoZSBJRCBvZiB0aGUgZW5kcG9pbnQgdG8gd2hpY2gg c3RhdHVzIHJlcG9ydHMgcGVydGFpbmluZyANCiAgICAgICAgICB0byB0aGUgZm9yd2FyZGluZyBh bmQgZGVsaXZlcnkgb2YgdGhpcyBidW5kbGUgYXJlIHRvIGJlIA0KICAgICAgICAgIHRyYW5zbWl0 dGVkLiANCiAgICANCiAgIFJlcG9ydC10byBTU1AgT2Zmc2V0LiAgVGhlIFJlcG9ydC10byBTU1Ag T2Zmc2V0IGZpZWxkIGNvbnRhaW5zIHRoZSANCiAgICAgICAgICBvZmZzZXQgd2l0aGluIHRoZSBk aWN0aW9uYXJ5IGJ5dGUgYXJyYXkgb2YgdGhlIHNjaGVtZS1zcGVjaWZpYyANCiAgICAgICAgICBw YXJ0IG9mIHRoZSBJRCBvZiB0aGUgZW5kcG9pbnQgdG8gd2hpY2ggc3RhdHVzIHJlcG9ydHMgDQog ICAgICAgICAgcGVydGFpbmluZyB0byB0aGUgZm9yd2FyZGluZyBhbmQgZGVsaXZlcnkgb2YgdGhp cyBidW5kbGUgYXJlIA0KICAgICAgICAgIHRvIGJlIHRyYW5zbWl0dGVkLiANCiAgICANCiAgIEN1 c3RvZGlhbiBTY2hlbWUgT2Zmc2V0LiAgVGhlICJjdXJyZW50IGN1c3RvZGlhbiBlbmRwb2ludCBJ RCIgb2YgYSANCiAgICAgICAgICBwcmltYXJ5IGJ1bmRsZSBibG9jayBpZGVudGlmaWVzIGFuIGVu ZHBvaW50IHdob3NlIG1lbWJlcnNoaXAgDQogICAgICAgICAgaW5jbHVkZXMgdGhlIG5vZGUgdGhh dCBtb3N0IHJlY2VudGx5IGFjY2VwdGVkIGN1c3RvZHkgb2YgdGhlIA0KICAgICAgICAgIGJ1bmRs ZSB1cG9uIGZvcndhcmRpbmcgdGhpcyBidW5kbGUuICBUaGUgQ3VzdG9kaWFuIFNjaGVtZSANCiAg ICAgICAgICBPZmZzZXQgZmllbGQgY29udGFpbnMgdGhlIG9mZnNldCB3aXRoaW4gdGhlIGRpY3Rp b25hcnkgYnl0ZSANCiAgICAgICAgICBhcnJheSBvZiB0aGUgc2NoZW1lIG5hbWUgb2YgdGhlIGN1 cnJlbnQgY3VzdG9kaWFuIGVuZHBvaW50IElELiANCiAgICANCiAgIEN1c3RvZGlhbiBTU1AgT2Zm c2V0LiAgVGhlIERlc3RpbmF0aW9uIFNTUCBPZmZzZXQgZmllbGQgY29udGFpbnMgdGhlIA0KICAg ICAgICAgIG9mZnNldCB3aXRoaW4gdGhlIGRpY3Rpb25hcnkgYnl0ZSBhcnJheSBvZiB0aGUgc2No ZW1lLXNwZWNpZmljIA0KICAgICAgICAgIHBhcnQgb2YgdGhlIGN1cnJlbnQgY3VzdG9kaWFuIGVu ZHBvaW50IElELiANCiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4cGlyZXMg LSBTZXB0ZW1iZXIgMjAwNyAgICBbUGFnZSAxN10gDQoMSW50ZXJuZXQgRHJhZnQgICAgICBCdW5k bGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcgDQogDQogDQogICAg DQogICBDcmVhdGlvbiBUaW1lc3RhbXAuICBUaGUgY3JlYXRpb24gdGltZXN0YW1wIGlzIGEgcGFp ciBvZiBTRE5WcyB0aGF0LCANCiAgICAgICAgICB0b2dldGhlciB3aXRoIHRoZSBzb3VyY2UgZW5k cG9pbnQgSUQgYW5kIChpZiB0aGUgYnVuZGxlIGlzIGEgDQogICAgICAgICAgZnJhZ21lbnQpIHRo ZSBmcmFnbWVudCBvZmZzZXQgYW5kIHBheWxvYWQgbGVuZ3RoLCBzZXJ2ZSB0byANCiAgICAgICAg ICBpZGVudGlmeSB0aGUgYnVuZGxlLiAgVGhlIGZpcnN0IFNETlYgb2YgdGhlIHRpbWVzdGFtcCBp cyB0aGUgDQogICAgICAgICAgYnVuZGxlJ3MgY3JlYXRpb24gdGltZSB3aGlsZSB0aGUgc2Vjb25k IGlzIHRoZSBidW5kbGUncyANCiAgICAgICAgICBjcmVhdGlvbiB0aW1lc3RhbXAgc2VxdWVuY2Ug bnVtYmVyLiAgQnVuZGxlIGNyZWF0aW9uIHRpbWUgaXMgDQogICAgICAgICAgdGhlIHRpbWUgLSBl eHByZXNzZWQgaW4gc2Vjb25kcyBzaW5jZSB0aGUgc3RhcnQgb2YgdGhlIHllYXIgDQogICAgICAg ICAgMjAwMCwgb24gdGhlIENvb3JkaW5hdGVkIFVuaXZlcnNhbCBUaW1lIChVVEMpIHNjYWxlIFs3 XSAtIGF0IA0KICAgICAgICAgIHdoaWNoIHRoZSB0cmFuc21pc3Npb24gcmVxdWVzdCB3YXMgcmVj ZWl2ZWQgdGhhdCByZXN1bHRlZCBpbiANCiAgICAgICAgICB0aGUgY3JlYXRpb24gb2YgdGhlIGJ1 bmRsZS4gIFNlcXVlbmNlIGNvdW50IGlzIHRoZSBsYXRlc3QgDQogICAgICAgICAgdmFsdWUgKGFz IG9mIHRoZSB0aW1lIGF0IHdoaWNoIHRoYXQgdHJhbnNtaXNzaW9uIHJlcXVlc3Qgd2FzIA0KICAg ICAgICAgIHJlY2VpdmVkKSBvZiBhIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZyBwb3NpdGl2ZSBp bnRlZ2VyIA0KICAgICAgICAgIGNvdW50ZXIgbWFuYWdlZCBieSB0aGUgc291cmNlIG5vZGUncyBi dW5kbGUgcHJvdG9jb2wgYWdlbnQgDQogICAgICAgICAgdGhhdCBtYXkgYmUgcmVzZXQgdG8gemVy byB3aGVuZXZlciB0aGUgY3VycmVudCB0aW1lIGFkdmFuY2VzIA0KICAgICAgICAgIGJ5IG9uZSBz ZWNvbmQuICBBIHNvdXJjZSBCdW5kbGUgUHJvdG9jb2wgQWdlbnQgbXVzdCBuZXZlciANCiAgICAg ICAgICBjcmVhdGUgdHdvIGRpc3RpbmN0IGJ1bmRsZXMgd2l0aCB0aGUgc2FtZSBzb3VyY2UgZW5k cG9pbnQgSUQgDQogICAgICAgICAgYW5kIGJ1bmRsZSBjcmVhdGlvbiB0aW1lc3RhbXAuICBUaGUg Y29tYmluYXRpb24gb2Ygc291cmNlIA0KICAgICAgICAgIGVuZHBvaW50IElEIGFuZCBidW5kbGUg Y3JlYXRpb24gdGltZXN0YW1wIHRoZXJlZm9yZSBzZXJ2ZXMgdG8gDQogICAgICAgICAgaWRlbnRp ZnkgYSBzaW5nbGUgdHJhbnNtaXNzaW9uIHJlcXVlc3QsIGVuYWJsaW5nIGl0IHRvIGJlIA0KICAg ICAgICAgIGFja25vd2xlZGdlZCBieSB0aGUgcmVjZWl2aW5nIGFwcGxpY2F0aW9uIChwcm92aWRl ZCB0aGUgc291cmNlIA0KICAgICAgICAgIGVuZHBvaW50IElEIGlzIG5vdCAiZHRuOm5vbmUiKS4g DQogICANCiAgIExpZmV0aW1lLiAgIFRoZSBsaWZldGltZSBmaWVsZCBpcyBhbiBTRE5WIHRoYXQg aW5kaWNhdGVzIHRoZSB0aW1lIGF0IA0KICAgICAgICAgIHdoaWNoIHRoZSBidW5kbGUncyBwYXls b2FkIHdpbGwgbm8gbG9uZ2VyIGJlIHVzZWZ1bCwgZW5jb2RlZCANCiAgICAgICAgICBhcyBhIG51 bWJlciBvZiBzZWNvbmRzIHBhc3QgdGhlIGNyZWF0aW9uIHRpbWUuICBXaGVuIHRoZSANCiAgICAg ICAgICBjdXJyZW50IHRpbWUgaXMgZ3JlYXRlciB0aGFuIHRoZSBjcmVhdGlvbiB0aW1lIHBsdXMg dGhlIA0KICAgICAgICAgIGxpZmV0aW1lLCBidW5kbGUgbm9kZXMgbmVlZCBubyBsb25nZXIgcmV0 YWluIG9yIGZvcndhcmQgdGhlIA0KICAgICAgICAgIGJ1bmRsZTsgdGhlIGJ1bmRsZSBtYXkgYmUg ZGVsZXRlZCBmcm9tIHRoZSBuZXR3b3JrLiANCiAgIA0KICAgRGljdGlvbmFyeSBMZW5ndGguICBU aGUgRGljdGlvbmFyeSBMZW5ndGggZmllbGQgaXMgYW4gU0ROViB0aGF0IA0KICAgICAgICAgIGNv bnRhaW5zIHRoZSBsZW5ndGggb2YgdGhlIGRpY3Rpb25hcnkgYnl0ZSBhcnJheS4gDQogICAgDQog ICBEaWN0aW9uYXJ5LiAgVGhlIERpY3Rpb25hcnkgZmllbGQgaXMgYW4gYXJyYXkgb2YgYnl0ZXMg Zm9ybWVkIGJ5IA0KICAgICAgICAgIGNvbmNhdGVuYXRpbmcgdGhlIG51bGwtdGVybWluYXRlZCBz Y2hlbWUgbmFtZXMgYW5kIFNTUHMgb2YgYWxsIA0KICAgICAgICAgIGVuZHBvaW50IElEcyByZWZl cmVuY2VkIGJ5IGFueSBmaWVsZHMgaW4gdGhpcyBQcmltYXJ5IEJsb2NrIA0KICAgICAgICAgIHRv Z2V0aGVyIHdpdGgsIHBvdGVudGlhbGx5LCBvdGhlciBlbmRwb2ludCBJRHMgcmVmZXJlbmNlZCBi eSANCiAgICAgICAgICBmaWVsZHMgaW4gb3RoZXIgVEJEIERUTiBwcm90b2NvbCBibG9ja3MuICBJ dHMgbGVuZ3RoIGlzIGdpdmVuIA0KICAgICAgICAgIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgRGljdGlv bmFyeSBMZW5ndGggZmllbGQuIA0KICAgIA0KICAgRnJhZ21lbnQgT2Zmc2V0LiAgSWYgdGhlIEJ1 bmRsZSBQcm9jZXNzaW5nIENvbnRyb2wgRmxhZ3Mgb2YgdGhpcyANCiAgICAgICAgICBQcmltYXJ5 IGJsb2NrIGluZGljYXRlIHRoYXQgdGhlIGJ1bmRsZSBpcyBhIGZyYWdtZW50LCB0aGVuIHRoZSAN CiAgICAgICAgICBGcmFnbWVudCBPZmZzZXQgZmllbGQgaXMgYW4gU0ROViBpbmRpY2F0aW5nIHRo ZSBvZmZzZXQgZnJvbSANCiAgICAgICAgICB0aGUgc3RhcnQgb2YgdGhlIG9yaWdpbmFsIGFwcGxp Y2F0aW9uIGRhdGEgdW5pdCBhdCB3aGljaCB0aGUgDQogICAgICAgICAgYnl0ZXMgY29tcHJpc2lu ZyB0aGUgcGF5bG9hZCBvZiB0aGlzIGJ1bmRsZSB3ZXJlIGxvY2F0ZWQuICBJZiANCiAgICAgICAg ICBub3QsIHRoZW4gdGhlIEZyYWdtZW50IE9mZnNldCBmaWVsZCBpcyBvbWl0dGVkIGZyb20gdGhl IGJsb2NrLiANCiAgICANCiAgIFRvdGFsIEFwcGxpY2F0aW9uIERhdGEgVW5pdCBMZW5ndGguICBJ ZiB0aGUgQnVuZGxlIFByb2Nlc3NpbmcgQ29udHJvbCANCiAgICAgICAgICBGbGFncyBvZiB0aGlz IFByaW1hcnkgYmxvY2sgaW5kaWNhdGUgdGhhdCB0aGUgYnVuZGxlIGlzIGEgDQogICAgICAgICAg ZnJhZ21lbnQsIHRoZW4gdGhlIFRvdGFsIEFwcGxpY2F0aW9uIERhdGEgVW5pdCBMZW5ndGggZmll bGQgaXMgDQogICAgICAgICAgYW4gU0ROViBpbmRpY2F0aW5nIHRoZSB0b3RhbCBsZW5ndGggb2Yg dGhlIG9yaWdpbmFsIA0KIA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJl cyAtIFNlcHRlbWJlciAyMDA3ICAgIFtQYWdlIDE4XSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1 bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCiAg ICAgICAgICBhcHBsaWNhdGlvbiBkYXRhIHVuaXQgb2Ygd2hpY2ggdGhpcyBidW5kbGUncyBwYXls b2FkIGlzIGEgDQogICAgICAgICAgcGFydC4gIElmIG5vdCwgdGhlbiB0aGUgVG90YWwgQXBwbGlj YXRpb24gRGF0YSBVbml0IExlbmd0aCANCiAgICAgICAgICBmaWVsZCBpcyBvbWl0dGVkIGZyb20g dGhlIGJsb2NrLiANCiAgIA0KMy42LjIgQnVuZGxlIFBheWxvYWQgQmxvY2sgDQogICANCiAgVGhl IGZpZWxkcyBvZiB0aGUgYnVuZGxlIHBheWxvYWQgYmxvY2sgYXJlOiANCiAgIA0KICAgQmxvY2sg VHlwZS4gIFRoZSBCbG9jayBUeXBlIGZpZWxkIGlzIGEgMS1ieXRlIGZpZWxkIHRoYXQgaW5kaWNh dGVzIA0KICAgICAgICAgIHRoZSB0eXBlIG9mIHRoZSBibG9jay4gIEZvciB0aGUgYnVuZGxlIHBh eWxvYWQgYmxvY2sgdGhpcyANCiAgICAgICAgICBmaWVsZCBjb250YWlucyB0aGUgdmFsdWUgMS4g DQogICAgDQogICBCbG9jayBQcm9jZXNzaW5nIENvbnRyb2wgRmxhZ3MuICBUaGUgQmxvY2sgUHJv Y2Vzc2luZyBDb250cm9sIEZsYWdzIA0KICAgICAgICAgIGZpZWxkIGlzIGFuIFNETlYgdGhhdCBj b250YWlucyB0aGUgYmxvY2sgcHJvY2Vzc2luZyBjb250cm9sIA0KICAgICAgICAgIGZsYWdzIGRp c2N1c3NlZCBpbiBzZWN0aW9uIDMuNCBhYm92ZS4gDQogICAgDQogICBCbG9jayBMZW5ndGguICBU aGUgQmxvY2sgTGVuZ3RoIGZpZWxkIGlzIGFuIFNETlYgdGhhdCBjb250YWlucyB0aGUgDQogICAg ICAgICAgYWdncmVnYXRlIGxlbmd0aCBvZiBhbGwgcmVtYWluaW5nIGZpZWxkcyBvZiB0aGUgYmxv Y2sgLSB3aGljaCANCiAgICAgICAgICBpcyB0byBzYXksIHRoZSBsZW5ndGggb2YgdGhlIGJ1bmRs ZSdzIHBheWxvYWQuIA0KICAgIA0KICAgUGF5bG9hZC4gIFRoZSBhcHBsaWNhdGlvbiBkYXRhIGNh cnJpZWQgYnkgdGhpcyBidW5kbGUuIA0KICAgIA0KMy43ICBFeHRlbnNpb24gQmxvY2tzIA0KICAg DQogICJFeHRlbnNpb24gYmxvY2tzIiBhcmUgYWxsIGJsb2NrcyBvdGhlciB0aGFuIHRoZSBwcmlt YXJ5IGFuZCBwYXlsb2FkIA0KICBibG9ja3MuICBCZWNhdXNlIGV4dGVuc2lvbiBibG9ja3MgYXJl IG5vdCBkZWZpbmVkIGluIHRoZSBCdW5kbGUgDQogIFByb3RvY29sIHNwZWNpZmljYXRpb24gKHRo ZSBwcmVzZW50IGRvY3VtZW50KSwgbm90IGFsbCBub2RlcyANCiAgY29uZm9ybWluZyB0byB0aGlz IHNwZWNpZmljYXRpb24gd2lsbCBuZWNlc3NhcmlseSBpbnN0YW50aWF0ZSBCdW5kbGUgDQogIFBy b3RvY29sIGltcGxlbWVudGF0aW9ucyB0aGF0IGluY2x1ZGUgcHJvY2VkdXJlcyBmb3IgcHJvY2Vz c2luZyAodGhhdCANCiAgaXMsIHJlY29nbml6aW5nLCBwYXJzaW5nLCBhY3Rpbmcgb24sIGFuZC9v ciBwcm9kdWNpbmcpIGFsbCBleHRlbnNpb24gDQogIGJsb2Nrcy4gIEl0IGlzIHRoZXJlZm9yZSBw b3NzaWJsZSBmb3IgYSBub2RlIHRvIHJlY2VpdmUgYSBidW5kbGUgdGhhdCANCiAgaW5jbHVkZXMg ZXh0ZW5zaW9uIGJsb2NrcyB3aGljaCB0aGUgbm9kZSBjYW5ub3QgcHJvY2Vzcy4gDQogICANCiAg QW55IGV4dGVuc2lvbiBibG9jayB0aGF0IGNvbnRhaW5zIGNpdGF0aW9ucyBvZiBlbmRwb2ludCBJ RHMgdGhhdCBhcmUgDQogIGNvbnRhaW5lZCBpbiB0aGUgZGljdGlvbmFyeSBvZiB0aGUgYnVuZGxl J3MgcHJpbWFyeSBibG9jayBzaG91bGQgaGF2ZSANCiAgdGhlICJEaXNjYXJkIGJsb2NrIGlmIGl0 IGNhbid0IGJlIHByb2Nlc3NlZCIgZmxhZyBzZXQgdG8gMSBpbiB0aGUgDQogIGJsb2NrIHByb2Nl c3NpbmcgZmxhZ3MgZmllbGQgb2YgdGhhdCBleHRlbnNpb24gYmxvY2suIA0KICAgDQogIEFueSBl eHRlbnNpb24gYmxvY2sgdGhhdCBoYXMgbmVpdGhlciB0aGUgIkRpc2NhcmQgYmxvY2sgaWYgaXQg Y2FuJ3QgDQogIGJlIHByb2Nlc3NlZCIgZmxhZyBub3IgdGhlICJEZWxldGUgYnVuZGxlIGlmIGJs b2NrIGNhbid0IGJlIA0KICBwcm9jZXNzZWQiIGZsYWcgc2V0IHRvIDEgaW4gaXRzIGJsb2NrIHBy b2Nlc3NpbmcgZmxhZ3MgZmllbGQgbXVzdCBub3QgDQogIGNvbnRhaW4gYW55IGNpdGF0aW9ucyBv ZiBlbmRwb2ludCBJRHMgdGhhdCBhcmUgY29udGFpbmVkIGluIHRoZSANCiAgZGljdGlvbmFyeSBv ZiB0aGUgYnVuZGxlJ3MgcHJpbWFyeSBibG9jay4gDQogICANCiAgV2hlbmV2ZXIgYSBidW5kbGUg aXMgZm9yd2FyZGVkIHRoYXQgY29udGFpbnMgb25lIG9yIG1vcmUgZXh0ZW5zaW9uIA0KICBibG9j a3MgdGhhdCBjb3VsZCBub3QgYmUgcHJvY2Vzc2VkLCB0aGUgIkJsb2NrIHdhcyBmb3J3YXJkZWQg d2l0aG91dCANCiAgYmVpbmcgcHJvY2Vzc2VkIiBmbGFnIG11c3QgYmUgc2V0IHRvIDEgd2l0aGlu IHRoZSBibG9jayBwcm9jZXNzaW5nIA0KICBmbGFncyBvZiBlYWNoIHN1Y2ggYmxvY2suICBGb3Ig ZWFjaCBibG9jayBmbGFnZ2VkIGluIHRoaXMgd2F5LCB0aGUgDQogIGZsYWcgbWF5IG9wdGlvbmFs bHkgYmUgY2xlYXJlZCAoaS5lLiwgc2V0IHRvIHplcm8pIGJ5IGFub3RoZXIgbm9kZSANCiAgdGhh dCBzdWJzZXF1ZW50bHkgcmVjZWl2ZXMgdGhlIGJ1bmRsZSBhbmQgaXMgYWJsZSB0byBwcm9jZXNz IHRoYXQgDQogIGJsb2NrOyB0aGUgc3BlY2lmaWNhdGlvbnMgZGVmaW5pbmcgdGhlIHZhcmlvdXMg ZXh0ZW5zaW9uIGJsb2NrcyBhcmUgDQogDQogDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAg ICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDcgICAgW1BhZ2UgMTldIA0KDEludGVybmV0IERyYWZ0 ICAgICAgQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0K IA0KIA0KICBleHBlY3RlZCB0byBkZWZpbmUgdGhlIGNpcmN1bXN0YW5jZXMgdW5kZXIgd2hpY2gg dGhpcyBmbGFnIG1heSBiZSANCiAgY2xlYXJlZCwgaWYgYW55LiANCiAgIA0KMy44ICBEaWN0aW9u YXJ5IHJldmlzaW9uIA0KICAgDQogIEFueSBvZiB0aGUgc3RyaW5ncyAoc2NoZW1lIG5hbWVzIGFu ZCBTU1BzKSBpbiBhIGJ1bmRsZSdzIGRpY3Rpb25hcnkgDQogIHRvIHdoaWNoIG5vIGVuZHBvaW50 IElEIHJlZmVyZW5jZXMgaW4gdGhlIGJ1bmRsZSBjdXJyZW50bHkgcmVmZXIgbWF5IA0KICBiZSBy ZW1vdmVkIGZyb20gdGhlIGRpY3Rpb25hcnkgYXQgdGhlIHRpbWUgdGhlIGJ1bmRsZSBpcyBmb3J3 YXJkZWQuIA0KICAgDQogIFdoZW5ldmVyIHJlbW92YWwgb2YgYSBzdHJpbmcgZnJvbSB0aGUgZGlj dGlvbmFyeSBjYXVzZXMgdGhlIG9mZnNldHMgDQogICh3aXRoaW4gdGhlIGRpY3Rpb25hcnkgYnl0 ZSBhcnJheSkgb2YgYW55IG90aGVyIHN0cmluZ3MgdG8gY2hhbmdlLCANCiAgYWxsIGVuZHBvaW50 IElEIHJlZmVyZW5jZXMgdGhhdCByZWZlciB0byB0aG9zZSBzdHJpbmdzIG11c3QgYmUgDQogIGFk anVzdGVkIGF0IHRoZSBzYW1lIHRpbWUuIA0KICAgDQo0LiAgIEJ1bmRsZSBQcm9jZXNzaW5nIA0K ICAgDQogIFRoZSBidW5kbGUgcHJvY2Vzc2luZyBwcm9jZWR1cmVzIG1hbmRhdGVkIGluIHRoaXMg c2VjdGlvbiBhbmQgaW4gDQogIHNlY3Rpb24gNSBnb3Zlcm4gdGhlIG9wZXJhdGlvbiBvZiB0aGUg QnVuZGxlIFByb3RvY29sIEFnZW50IGFuZCB0aGUgDQogIEFwcGxpY2F0aW9uIEFnZW50IGFkbWlu aXN0cmF0aXZlIGVsZW1lbnQgb2YgZWFjaCBidW5kbGUgbm9kZS4gIFRoZXkgDQogIGFyZSBuZWl0 aGVyIGV4aGF1c3RpdmUgbm9yIGV4Y2x1c2l2ZS4gIFRoYXQgaXMsIHN1cHBsZW1lbnRhcnkgRFRO IA0KICBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyAoaW5jbHVkaW5nLCBidXQgbm90IHJlc3RyaWN0 ZWQgdG8sIHRoZSBCdW5kbGUgDQogIFNlY3VyaXR5IFByb3RvY29sIFs1XSkgbWF5IHJlcXVpcmUg dGhhdCBhZGRpdGlvbmFsIG1lYXN1cmVzIGJlIHRha2VuIA0KICBhdCBzcGVjaWZpZWQganVuY3R1 cmVzIGluIHRoZXNlIHByb2NlZHVyZXMuICBTdWNoIGFkZGl0aW9uYWwgbWVhc3VyZXMgDQogIHNo YWxsIG5vdCBvdmVycmlkZSBvciBzdXBlcnNlZGUgdGhlIG1hbmRhdGVkIGJ1bmRsZSBwcm90b2Nv bCANCiAgcHJvY2VkdXJlcywgZXhjZXB0IHRoYXQgdGhleSBtYXkgaW4gc29tZSBjYXNlcyBtYWtl IHRoZXNlIHByb2NlZHVyZXMgDQogIG1vb3QgYnkgcmVxdWlyaW5nLCBmb3IgZXhhbXBsZSwgdGhh dCBpbXBsZW1lbnRhdGlvbnMgY29uZm9ybWluZyB0byANCiAgdGhlIHN1cHBsZW1lbnRhcnkgcHJv dG9jb2wgdGVybWluYXRlIHRoZSBwcm9jZXNzaW5nIG9mIGEgZ2l2ZW4gDQogIGluY29taW5nIG9y IG91dGdvaW5nIGJ1bmRsZSBkdWUgdG8gYSBmYXVsdCBjb25kaXRpb24gcmVjb2duaXplZCBieSAN CiAgdGhhdCBwcm90b2NvbC4gDQogICANCjQuMSBHZW5lcmF0aW9uIG9mIGFkbWluaXN0cmF0aXZl IHJlY29yZHMgDQogICANCiAgQWxsIGluaXRpYWwgdHJhbnNtaXNzaW9uIG9mIGJ1bmRsZXMgaXMg aW4gcmVzcG9uc2UgdG8gYnVuZGxlIA0KICB0cmFuc21pc3Npb24gcmVxdWVzdHMgcHJlc2VudGVk IGJ5IG5vZGVzJyBhcHBsaWNhdGlvbiBhZ2VudHMuICBXaGVuIA0KICByZXF1aXJlZCB0byAiZ2Vu ZXJhdGUiIGFuIGFkbWluaXN0cmF0aXZlIHJlY29yZCAoYSBidW5kbGUgc3RhdHVzIA0KICByZXBv cnQgb3IgYSBjdXN0b2R5IHNpZ25hbCksIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgaXRzZWxm IGlzIA0KICByZXNwb25zaWJsZSBmb3IgY2F1c2luZyBhIG5ldyBidW5kbGUgdG8gYmUgdHJhbnNt aXR0ZWQsIGNvbnZleWluZyANCiAgdGhhdCByZWNvcmQuICBJbiBjb25jZXB0LCB0aGUgYnVuZGxl IHByb3RvY29sIGFnZW50IGRpc2NoYXJnZXMgdGhpcyANCiAgcmVzcG9uc2liaWxpdHkgYnkgZGly ZWN0aW5nIHRoZSBhZG1pbmlzdHJhdGl2ZSBlbGVtZW50IG9mIHRoZSBub2RlJ3MgDQogIGFwcGxp Y2F0aW9uIGFnZW50IHRvIGNvbnN0cnVjdCB0aGUgcmVjb3JkIGFuZCByZXF1ZXN0IGl0cyANCiAg dHJhbnNtaXNzaW9uIGFzIGRldGFpbGVkIGluIHNlY3Rpb24gNSBiZWxvdzsgaW4gcHJhY3RpY2Us IHRoZSBtYW5uZXIgDQogIGluIHdoaWNoIGFkbWluaXN0cmF0aXZlIHJlY29yZCBnZW5lcmF0aW9u IGlzIGFjY29tcGxpc2hlZCBpcyBhbiANCiAgaW1wbGVtZW50YXRpb24gbWF0dGVyLCBwcm92aWRl ZCB0aGUgY29uc3RyYWludHMgbm90ZWQgaW4gc2VjdGlvbiA1IA0KICBhcmUgb2JzZXJ2ZWQuIA0K ICAgDQogIFVuZGVyIHNvbWUgY2lyY3Vtc3RhbmNlcyB0aGUgcmVxdWVzdGluZyBvZiBzdGF0dXMg cmVwb3J0cyBjb3VsZCANCiAgcmVzdWx0IGluIGFuIHVuYWNjZXB0YWJsZSBpbmNyZWFzZSBpbiB0 aGUgYnVuZGxlIHRyYWZmaWMgaW4gdGhlIA0KICBuZXR3b3JrLiAgRm9yIHRoaXMgcmVhc29uLCB0 aGUgZ2VuZXJhdGlvbiBvZiBzdGF0dXMgcmVwb3J0cyBpcyANCiAgbWFuZGF0b3J5IG9ubHkgaW4g b25lIGNhc2UsIHRoZSBkZWxldGlvbiBvZiBhIGJ1bmRsZSBmb3Igd2hpY2ggDQogIGN1c3RvZHkg dHJhbnNmZXIgaXMgcmVxdWVzdGVkLiAgSW4gYWxsIG90aGVyIGNhc2VzIHRoZSBkZWNpc2lvbiBv biANCiAgd2hldGhlciBvciBub3QgdG8gZ2VuZXJhdGUgYSByZXF1ZXN0ZWQgc3RhdHVzIHJlcG9y dCBpcyBsZWZ0IHRvIHRoZSANCiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4 cGlyZXMgLSBTZXB0ZW1iZXIgMjAwNyAgICBbUGFnZSAyMF0gDQoMSW50ZXJuZXQgRHJhZnQgICAg ICBCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcgDQogDQog DQogIGRpc2NyZXRpb24gb2YgdGhlIGJ1bmRsZSBwcm90b2NvbCBhZ2VudC4gIE1lY2hhbmlzbXMg dGhhdCBjb3VsZCANCiAgYXNzaXN0IGluIG1ha2luZyBzdWNoIGRlY2lzaW9ucywgc3VjaCBhcyBw cmUtcGxhY2VkIGFncmVlbWVudHMgDQogIGF1dGhvcml6aW5nIHRoZSBnZW5lcmF0aW9uIG9mIHN0 YXR1cyByZXBvcnRzIHVuZGVyIHNwZWNpZmllZCANCiAgY2lyY3Vtc3RhbmNlcywgYXJlIGJleW9u ZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiAgICANCiAgIA0KICBOb3RlcyBvbiBh ZG1pbmlzdHJhdGl2ZSByZWNvcmQgdGVybWlub2xvZ3k6IA0KICAgDQogIGEuIEEgImJ1bmRsZSBy ZWNlcHRpb24gc3RhdHVzIHJlcG9ydCIgaXMgYSBidW5kbGUgc3RhdHVzIHJlcG9ydCB3aXRoIA0K ICB0aGUgInJlcG9ydGluZyBub2RlIHJlY2VpdmVkIGJ1bmRsZSIgZmxhZyBzZXQgdG8gMS4gDQog ICANCiAgYi4gQSAiY3VzdG9keSBhY2NlcHRhbmNlIHN0YXR1cyByZXBvcnQiIGlzIGEgYnVuZGxl IHN0YXR1cyByZXBvcnQgDQogIHdpdGggdGhlICJyZXBvcnRpbmcgbm9kZSBhY2NlcHRlZCBjdXN0 b2R5IG9mIGJ1bmRsZSIgZmxhZyBzZXQgdG8gMS4gDQogICANCiAgYy4gQSAiYnVuZGxlIGZvcndh cmRpbmcgc3RhdHVzIHJlcG9ydCIgaXMgYSBidW5kbGUgc3RhdHVzIHJlcG9ydCB3aXRoIA0KICB0 aGUgInJlcG9ydGluZyBub2RlIGZvcndhcmRlZCB0aGUgYnVuZGxlIiBmbGFnIHNldCB0byAxLiAN CiAgIA0KICBkLiBBICJidW5kbGUgZGVsaXZlcnkgc3RhdHVzIHJlcG9ydCIgaXMgYSBidW5kbGUg c3RhdHVzIHJlcG9ydCB3aXRoIA0KICB0aGUgInJlcG9ydGluZyBub2RlIGRlbGl2ZXJlZCB0aGUg YnVuZGxlIiBmbGFnIHNldCB0byAxLiANCiAgIA0KICBlLiBBICJidW5kbGUgZGVsZXRpb24gc3Rh dHVzIHJlcG9ydCIgaXMgYSBidW5kbGUgc3RhdHVzIHJlcG9ydCB3aXRoIA0KICB0aGUgInJlcG9y dGluZyBub2RlIGRlbGV0ZWQgdGhlIGJ1bmRsZSIgZmxhZyBzZXQgdG8gMS4gDQogICANCiAgZi4g QSAiU3VjY2VlZGVkIiBjdXN0b2R5IHNpZ25hbCBpcyBhIGN1c3RvZHkgc2lnbmFsIHdpdGggdGhl ICJjdXN0b2R5IA0KICB0cmFuc2ZlciBzdWNjZWVkZWQiIGZsYWcgc2V0IHRvIDEuICAgIA0KICAg DQogIGcuIEEgIkZhaWxlZCIgY3VzdG9keSBzaWduYWwgaXMgYSBjdXN0b2R5IHNpZ25hbCB3aXRo IHRoZSAiY3VzdG9keSANCiAgdHJhbnNmZXIgc3VjY2VlZGVkIiBmbGFnIHNldCB0byB6ZXJvLiAN CiAgIA0KICBoLiBUaGUgImN1cnJlbnQgY3VzdG9kaWFuIiBvZiBhIGJ1bmRsZSBpcyB0aGUgZW5k cG9pbnQgaWRlbnRpZmllZCBieSANCiAgdGhlIGN1cnJlbnQgY3VzdG9kaWFuIGVuZHBvaW50IElE IGluIHRoZSBidW5kbGUncyBwcmltYXJ5IGJsb2NrLiANCiAgIA0KNC4yIEJ1bmRsZSB0cmFuc21p c3Npb24gDQogICANCiAgVGhlIHN0ZXBzIGluIHByb2Nlc3NpbmcgYSBidW5kbGUgdHJhbnNtaXNz aW9uIHJlcXVlc3QgYXJlOiANCiAgIA0KICBTdGVwIDE6IElmIGN1c3RvZHkgdHJhbnNmZXIgaXMg cmVxdWVzdGVkIGZvciB0aGlzIGJ1bmRsZSB0cmFuc21pc3Npb24gDQogIGFuZCwgbW9yZW92ZXIs IGN1c3RvZHkgYWNjZXB0YW5jZSBieSB0aGUgc291cmNlIG5vZGUgaXMgcmVxdWlyZWQsIA0KICB0 aGVuIGVpdGhlciB0aGUgYnVuZGxlIHByb3RvY29sIGFnZW50IG11c3QgY29tbWl0IHRvIGFjY2Vw dGluZyANCiAgY3VzdG9keSBvZiB0aGUgYnVuZGxlIC0gaW4gd2hpY2ggY2FzZSBwcm9jZXNzaW5n IHByb2NlZWRzIGZyb20gU3RlcCAyIA0KICAtIG9yIGVsc2UgdGhlIHJlcXVlc3QgY2Fubm90IGJl IGhvbm9yZWQgYW5kIGFsbCByZW1haW5pbmcgc3RlcHMgb2YgDQogIHRoaXMgcHJvY2VkdXJlIG11 c3QgYmUgc2tpcHBlZC4gIFRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgbXVzdCBub3QgDQogIGNv bW1pdCB0byBhY2NlcHRpbmcgY3VzdG9keSBvZiBhIGJ1bmRsZSBpZiB0aGUgY29uZGl0aW9ucyB1 bmRlciB3aGljaCANCiAgY3VzdG9keSBvZiB0aGUgYnVuZGxlIG1heSBiZSBhY2NlcHRlZCBhcmUg bm90IHNhdGlzZmllZC4gIFRoZSANCiAgY29uZGl0aW9ucyB1bmRlciB3aGljaCBhIG5vZGUgbWF5 IGFjY2VwdCBjdXN0b2R5IG9mIGEgYnVuZGxlIHdob3NlIA0KICBkZXN0aW5hdGlvbiBpcyBub3Qg YSBzaW5nbGV0b24gZW5kcG9pbnQgYXJlIG5vdCBkZWZpbmVkIGluIHRoaXMgDQogIHNwZWNpZmlj YXRpb24uICANCiAgIA0KICBTdGVwIDI6IFRyYW5zbWlzc2lvbiBvZiB0aGUgYnVuZGxlIGlzIGlu aXRpYXRlZC4gIEFuIG91dGJvdW5kIGJ1bmRsZSANCiAgbXVzdCBiZSBjcmVhdGVkIHBlciB0aGUg cGFyYW1ldGVycyBvZiB0aGUgYnVuZGxlIHRyYW5zbWlzc2lvbiANCiAgcmVxdWVzdCwgd2l0aCBj dXJyZW50IGN1c3RvZGlhbiBlbmRwb2ludCBJRCBzZXQgdG8gdGhlIG51bGwgZW5kcG9pbnQgDQog IElEICJkdG46bm9uZSIgYW5kIHdpdGggdGhlIHJldGVudGlvbiBjb25zdHJhaW50ICJEaXNwYXRj aCBwZW5kaW5nIi4gIA0KIA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJl cyAtIFNlcHRlbWJlciAyMDA3ICAgIFtQYWdlIDIxXSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1 bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCiAg VGhlIHNvdXJjZSBlbmRwb2ludCBJRCBvZiB0aGUgYnVuZGxlIG11c3QgYmUgZWl0aGVyIHRoZSBJ RCBvZiBhbiANCiAgZW5kcG9pbnQgb2Ygd2hpY2ggdGhlIG5vZGUgaXMgYSBtZW1iZXIgb3IgZWxz ZSB0aGUgbnVsbCBlbmRwb2ludCBJRCANCiAgImR0bjpub25lIi4gIA0KICAgDQogIFN0ZXAgMzog UHJvY2Vzc2luZyBwcm9jZWVkcyBmcm9tIFN0ZXAgMSBvZiBzZWN0aW9uIDQuMy4gDQogICANCjQu MyBCdW5kbGUgZGlzcGF0Y2hpbmcgDQogICANCiAgVGhlIHN0ZXBzIGluIGRpc3BhdGNoaW5nIGEg YnVuZGxlIGFyZTogDQogICANCiAgU3RlcCAxOiBJZiB0aGUgYnVuZGxlJ3MgZGVzdGluYXRpb24g ZW5kcG9pbnQgaXMgYW4gZW5kcG9pbnQgb2Ygd2hpY2ggDQogIHRoZSBub2RlIGlzIGEgbWVtYmVy LCB0aGUgYnVuZGxlIGRlbGl2ZXJ5IHByb2NlZHVyZSBkZWZpbmVkIGluIDQuNyANCiAgbXVzdCBi ZSBmb2xsb3dlZC4gDQogICANCiAgU3RlcCAyOiBQcm9jZXNzaW5nIHByb2NlZWRzIGZyb20gU3Rl cCAxIG9mIHNlY3Rpb24gNC40LiANCiAgIA0KNC40IEJ1bmRsZSBmb3J3YXJkaW5nIA0KICAgDQog IFRoZSBzdGVwcyBpbiBmb3J3YXJkaW5nIGEgYnVuZGxlIGFyZTogDQogICANCiAgU3RlcCAxOiBU aGUgcmV0ZW50aW9uIGNvbnN0cmFpbnQgIkZvcndhcmQgcGVuZGluZyIgbXVzdCBiZSBhZGRlZCB0 byANCiAgdGhlIGJ1bmRsZSwgYW5kIHRoZSBidW5kbGUncyAiRGlzcGF0Y2ggcGVuZGluZyIgcmV0 ZW50aW9uIGNvbnN0cmFpbnQgDQogIG11c3QgYmUgcmVtb3ZlZC4gDQogICANCiAgU3RlcCAyOiBU aGUgYnVuZGxlIHByb3RvY29sIGFnZW50IG11c3QgZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IA0K ICBmb3J3YXJkaW5nIGlzIGNvbnRyYWluZGljYXRlZCBmb3IgYW55IG9mIHRoZSByZWFzb25zIGxp c3RlZCBpbiBUYWJsZSANCiAgNC4gIEluIHBhcnRpY3VsYXI6IA0KICAgDQogICBvIFRoZSBidW5k bGUgcHJvdG9jb2wgYWdlbnQgbXVzdCBkZXRlcm1pbmUgd2hpY2ggZW5kcG9pbnQocykgdG8gDQog IGZvcndhcmQgdGhlIGJ1bmRsZSB0by4gIFRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgbWF5IGNo b29zZSBlaXRoZXIgDQogIHRvIGZvcndhcmQgdGhlIGJ1bmRsZSBkaXJlY3RseSB0byBpdHMgZGVz dGluYXRpb24gZW5kcG9pbnQgKGlmIA0KICBwb3NzaWJsZSkgb3IgZWxzZSB0byBmb3J3YXJkIHRo ZSBidW5kbGUgdG8gc29tZSBvdGhlciBlbmRwb2ludChzKSBmb3IgDQogIGZ1cnRoZXIgZm9yd2Fy ZGluZy4gIFRoZSBtYW5uZXIgaW4gd2hpY2ggdGhpcyBkZWNpc2lvbiBpcyBtYWRlIG1heSANCiAg ZGVwZW5kIG9uIHRoZSBzY2hlbWUgbmFtZSBpbiB0aGUgZGVzdGluYXRpb24gZW5kcG9pbnQgSUQg YnV0IGluIGFueSANCiAgY2FzZSBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQu ICBJZiB0aGUgYWdlbnQgZmluZHMgaXQgDQogIGltcG9zc2libGUgdG8gc2VsZWN0IGFueSBlbmRw b2ludChzKSB0byBmb3J3YXJkIHRoZSBidW5kbGUgdG8sIHRoZW4gDQogIGZvcndhcmRpbmcgaXMg Y29udHJhaW5kaWNhdGVkLiANCiAgIA0KICAgbyBQcm92aWRlZCB0aGUgYnVuZGxlIHByb3RvY29s IGFnZW50IHN1Y2NlZWRlZCBpbiBzZWxlY3RpbmcgdGhlIA0KICBlbmRwb2ludChzKSB0byBmb3J3 YXJkIHRoZSBidW5kbGUgdG8sIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgbXVzdCANCiAgc2Vs ZWN0IHRoZSBjb252ZXJnZW5jZSBsYXllciBhZGFwdGVyKHMpIHdob3NlIHNlcnZpY2VzIHdpbGwg ZW5hYmxlIA0KICB0aGUgbm9kZSB0byBzZW5kIHRoZSBidW5kbGUgdG8gdGhlIG5vZGVzIG9mIHRo ZSBtaW5pbXVtIHJlY2VwdGlvbiANCiAgZ3JvdXAgb2YgZWFjaCBzZWxlY3RlZCBlbmRwb2ludC4g IFRoZSBtYW5uZXIgaW4gd2hpY2ggdGhlIGFwcHJvcHJpYXRlIA0KICBjb252ZXJnZW5jZSBsYXll ciBhZGFwdGVycyBhcmUgc2VsZWN0ZWQgbWF5IGRlcGVuZCBvbiB0aGUgc2NoZW1lIG5hbWUgDQog IGluIHRoZSBkZXN0aW5hdGlvbiBlbmRwb2ludCBJRCBidXQgaW4gYW55IGNhc2UgaXMgYmV5b25k IHRoZSBzY29wZSBvZiANCiAgdGhpcyBkb2N1bWVudC4gIElmIHRoZSBhZ2VudCBmaW5kcyBpdCBp bXBvc3NpYmxlIHRvIHNlbGVjdCANCiAgY29udmVyZ2VuY2UgbGF5ZXIgYWRhcHRlcnMgdG8gdXNl IGluIGZvcndhcmRpbmcgdGhpcyBidW5kbGUsIHRoZW4gDQogIGZvcndhcmRpbmcgaXMgY29udHJh aW5kaWNhdGVkLiANCiAgIA0KICBTdGVwIDM6IElmIGZvcndhcmRpbmcgb2YgdGhlIGJ1bmRsZSBp cyBkZXRlcm1pbmVkIHRvIGJlIA0KICBjb250cmFpbmRpY2F0ZWQgZm9yIGFueSBvZiB0aGUgcmVh c29ucyBsaXN0ZWQgaW4gVGFibGUgNCwgdGhlbiB0aGUgDQogDQogDQpLLiBTY290dCBhbmQgUy4g QnVybGVpZ2ggICAgICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDcgICAgW1BhZ2UgMjJdIA0KDElu dGVybmV0IERyYWZ0ICAgICAgQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBN YXJjaCAyMDA3IA0KIA0KIA0KICBGb3J3YXJkaW5nIENvbnRyYWluZGljYXRlZCBwcm9jZWR1cmUg ZGVmaW5lZCBpbiA0LjQuMSBtdXN0IGJlIA0KICBmb2xsb3dlZDsgdGhlIHJlbWFpbmluZyBzdGVw cyBvZiBzZWN0aW9uIDQgYXJlIHNraXBwZWQgYXQgdGhpcyB0aW1lLiANCiAgIA0KICBTdGVwIDQ6 IElmIHRoZSBidW5kbGUncyBjdXN0b2R5IHRyYW5zZmVyIHJlcXVlc3RlZCBmbGFnIChpbiB0aGUg DQogIGJ1bmRsZSBwcm9jZXNzaW5nIGZsYWdzIGZpZWxkKSBpcyBzZXQgdG8gMSB0aGVuIHRoZSBj dXN0b2R5IHRyYW5zZmVyIA0KICBwcm9jZWR1cmUgZGVmaW5lZCBpbiBzZWN0aW9uIDQuMTAgbXVz dCBiZSBmb2xsb3dlZC4gDQogICANCiAgU3RlcCA1OiBGb3IgZWFjaCBlbmRwb2ludCBzZWxlY3Rl ZCBmb3IgZm9yd2FyZGluZywgdGhlIGJ1bmRsZSANCiAgcHJvdG9jb2wgYWdlbnQgbXVzdCBpbnZv a2UgdGhlIHNlcnZpY2VzIG9mIHRoZSBzZWxlY3RlZCBjb252ZXJnZW5jZSANCiAgbGF5ZXIgYWRh cHRlcihzKSBpbiBvcmRlciB0byBlZmZlY3QgdGhlIHNlbmRpbmcgb2YgdGhlIGJ1bmRsZSB0byB0 aGUgDQogIG5vZGVzIGNvbnN0aXR1dGluZyB0aGUgbWluaW11bSByZWNlcHRpb24gZ3JvdXAgb2Yg dGhhdCBlbmRwb2ludC4gIA0KICBEZXRlcm1pbmluZyB0aGUgdGltZSBhdCB3aGljaCB0aGUgYnVu ZGxlIGlzIHRvIGJlIHNlbnQgYnkgZWFjaCANCiAgY29udmVyZ2VuY2UgbGF5ZXIgYWRhcHRlciBp cyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIuIA0KICAgDQogIFN0ZXAgNjogV2hlbiBhbGwgc2Vs ZWN0ZWQgY29udmVyZ2VuY2UgbGF5ZXIgYWRhcHRlcnMgaGF2ZSBpbmZvcm1lZCANCiAgdGhlIGJ1 bmRsZSBwcm90b2NvbCBhZ2VudCB0aGF0IHRoZXkgaGF2ZSBjb25jbHVkZWQgdGhlaXIgZGF0YSBz ZW5kaW5nIA0KICBwcm9jZWR1cmVzIHdpdGggcmVnYXJkIHRvIHRoaXMgYnVuZGxlOiANCiAgIA0K ICAgbyBJZiB0aGUgInJlcXVlc3QgcmVwb3J0aW5nIG9mIGJ1bmRsZSBmb3J3YXJkaW5nIiBmbGFn IGluIHRoZSANCiAgYnVuZGxlJ3Mgc3RhdHVzIHJlcG9ydCByZXF1ZXN0IGZpZWxkIGlzIHNldCB0 byAxLCB0aGVuIGEgYnVuZGxlIA0KICBmb3J3YXJkaW5nIHN0YXR1cyByZXBvcnQgc2hvdWxkIGJl IGdlbmVyYXRlZCwgZGVzdGluZWQgZm9yIHRoZSANCiAgYnVuZGxlJ3MgcmVwb3J0LXRvIGVuZHBv aW50IElELiAgSWYgdGhlIGJ1bmRsZSBoYXMgdGhlIHJldGVudGlvbiANCiAgY29uc3RyYWludCAi Y3VzdG9keSBhY2NlcHRlZCIgYW5kIGFsbCBvZiB0aGUgbm9kZXMgaW4gdGhlIG1pbmltdW0gDQog IHJlY2VwdGlvbiBncm91cCBvZiB0aGUgZW5kcG9pbnQgc2VsZWN0ZWQgZm9yIGZvcndhcmRpbmcg YXJlIGtub3duIHRvIA0KICBiZSB1bmFibGUgdG8gc2VuZCBidW5kbGVzIGJhY2sgdG8gdGhpcyBu b2RlLCB0aGVuIHRoZSByZWFzb24gY29kZSBvbiANCiAgdGhpcyBidW5kbGUgZm9yd2FyZGluZyBz dGF0dXMgcmVwb3J0IG11c3QgYmUgImZvcndhcmRlZCBvdmVyIA0KICB1bmlkaXJlY3Rpb25hbCBs aW5rIjsgb3RoZXJ3aXNlIHRoZSByZWFzb24gY29kZSBtdXN0IGJlICJubyANCiAgYWRkaXRpb25h bCBpbmZvcm1hdGlvbiIuICANCiAgIA0KICAgbyBUaGUgYnVuZGxlJ3MgIkZvcndhcmQgcGVuZGlu ZyIgcmV0ZW50aW9uIGNvbnN0cmFpbnQgbXVzdCBiZSANCiAgcmVtb3ZlZC4gDQogICANCjQuNC4x IEZvcndhcmRpbmcgQ29udHJhaW5kaWNhdGVkIA0KICAgDQogIFRoZSBzdGVwcyBpbiByZXNwb25k aW5nIHRvIGNvbnRyYWluZGljYXRpb24gb2YgZm9yd2FyZGluZyBmb3Igc29tZSANCiAgcmVhc29u IGFyZTogDQogICANCiAgU3RlcCAxOiBUaGUgYnVuZGxlIHByb3RvY29sIGFnZW50IG11c3QgZGV0 ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIA0KICBkZWNsYXJlIGZhaWx1cmUgaW4gZm9yd2FyZGlu ZyB0aGUgYnVuZGxlIGZvciB0aGlzIHJlYXNvbi4gIE5vdGU6IHRoaXMgDQogIGRlY2lzaW9uIGlz IGxpa2VseSB0byBiZSBpbmZsdWVuY2VkIGJ5IHRoZSByZWFzb24gZm9yIHdoaWNoIA0KICBmb3J3 YXJkaW5nIGlzIGNvbnRyYWluZGljYXRlZC4gDQogICANCiAgU3RlcCAyOiBJZiBmb3J3YXJkaW5n IGZhaWx1cmUgaXMgZGVjbGFyZWQsIHRoZW4gdGhlIEZvcndhcmRpbmcgRmFpbGVkIA0KICBwcm9j ZWR1cmUgZGVmaW5lZCBpbiA0LjQuMiBtdXN0IGJlIGZvbGxvd2VkLiAgT3RoZXJ3aXNlLCAoYSkg aWYgdGhlIA0KICBidW5kbGUncyBjdXN0b2R5IHRyYW5zZmVyIHJlcXVlc3RlZCBmbGFnIChpbiB0 aGUgYnVuZGxlIHByb2Nlc3NpbmcgDQogIGZsYWdzIGZpZWxkKSBpcyBzZXQgdG8gMSB0aGVuIHRo ZSBjdXN0b2R5IHRyYW5zZmVyIHByb2NlZHVyZSBkZWZpbmVkIA0KICBpbiBzZWN0aW9uIDQuMTAg bXVzdCBiZSBmb2xsb3dlZDsgKGIpIHdoZW4gLSBhdCBzb21lIGZ1dHVyZSB0aW1lIC0gDQogIHRo ZSBmb3J3YXJkaW5nIG9mIHRoaXMgYnVuZGxlIGNlYXNlcyB0byBiZSBjb250cmFpbmRpY2F0ZWQs IA0KICBwcm9jZXNzaW5nIHByb2NlZWRzIGZyb20gU3RlcCA1IG9mIDQuNC4gDQogICANCg0KIA0K IA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJlcyAtIFNlcHRlbWJlciAyMDA3 ICAgIFtQYWdlIDIzXSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1bmRsZSBQcm90b2NvbCBTcGVj aWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCjQuNC4yIEZvcndhcmRpbmcgRmFp bGVkIA0KICAgDQogIFRoZSBzdGVwcyBpbiByZXNwb25kaW5nIHRvIGEgZGVjbGFyYXRpb24gb2Yg Zm9yd2FyZGluZyBmYWlsdXJlIGZvciANCiAgc29tZSByZWFzb24gYXJlOiANCiAgIA0KICBTdGVw IDE6IElmIHRoZSBidW5kbGUncyBjdXN0b2R5IHRyYW5zZmVyIHJlcXVlc3RlZCBmbGFnIChpbiB0 aGUgDQogIGJ1bmRsZSBwcm9jZXNzaW5nIGZsYWdzIGZpZWxkKSBpcyBzZXQgdG8gMSwgY3VzdG9k eSB0cmFuc2ZlciBmYWlsdXJlIA0KICBtdXN0IGJlIGhhbmRsZWQuICBQcm9jZWR1cmVzIGZvciBo YW5kbGluZyBmYWlsdXJlIG9mIGN1c3RvZHkgdHJhbnNmZXIgDQogIGZvciBhIGJ1bmRsZSB3aG9z ZSBkZXN0aW5hdGlvbiBpcyBub3QgYSBzaW5nbGV0b24gZW5kcG9pbnQgYXJlIG5vdCANCiAgZGVm aW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24uICBGb3IgYSBidW5kbGUgd2hvc2UgZGVzdGluYXRp b24gaXMgYSANCiAgc2luZ2xldG9uIGVuZHBvaW50LCB0aGUgYnVuZGxlIHByb3RvY29sIGFnZW50 IG11c3QgaGFuZGxlIHRoZSBjdXN0b2R5IA0KICB0cmFuc2ZlciBmYWlsdXJlIGJ5IGdlbmVyYXRp bmcgYSAiRmFpbGVkIiBjdXN0b2R5IHNpZ25hbCBmb3IgdGhlIA0KICBidW5kbGUsIGRlc3RpbmVk IGZvciB0aGUgYnVuZGxlJ3MgY3VycmVudCBjdXN0b2RpYW47IHRoZSBjdXN0b2R5IA0KICBzaWdu YWwgbXVzdCBjb250YWluIGEgcmVhc29uIGNvZGUgY29ycmVzcG9uZGluZyB0byB0aGUgcmVhc29u IGZvciANCiAgd2hpY2ggZm9yd2FyZGluZyB3YXMgZGV0ZXJtaW5lZCB0byBiZSBjb250cmFpbmRp Y2F0ZWQuIChOb3RlIHRoYXQgDQogIGRpc2NhcmRpbmcgdGhlIGJ1bmRsZSB3aWxsIG5vdCBkZWxl dGUgaXQgZnJvbSB0aGUgbmV0d29yaywgc2luY2UgdGhlIA0KICBjdXJyZW50IGN1c3RvZGlhbiBz dGlsbCBoYXMgYSBjb3B5LikgDQogICANCiAgU3RlcCAyOiBJZiB0aGUgYnVuZGxlJ3MgZGVzdGlu YXRpb24gZW5kcG9pbnQgaXMgYW4gZW5kcG9pbnQgb2Ygd2hpY2ggDQogIHRoZSBub2RlIGlzIGEg bWVtYmVyLCB0aGVuIHRoZSBidW5kbGUncyAiRm9yd2FyZCBwZW5kaW5nIiByZXRlbnRpb24gDQog IGNvbnN0cmFpbnQgbXVzdCBiZSByZW1vdmVkLiAgT3RoZXJ3aXNlIHRoZSBidW5kbGUgbXVzdCBi ZSBkZWxldGVkOiANCiAgdGhlIGJ1bmRsZSBkZWxldGlvbiBwcm9jZWR1cmUgZGVmaW5lZCBpbiA0 LjEzIG11c3QgYmUgZm9sbG93ZWQsIA0KICBjaXRpbmcgdGhlIHJlYXNvbiBmb3Igd2hpY2ggZm9y d2FyZGluZyB3YXMgZGV0ZXJtaW5lZCB0byBiZSANCiAgY29udHJhaW5kaWNhdGVkLiANCiAgIA0K NC41IEJ1bmRsZSBleHBpcmF0aW9uIA0KICAgDQogIEEgYnVuZGxlIGV4cGlyZXMgd2hlbiB0aGUg Y3VycmVudCB0aW1lIGlzIGdyZWF0ZXIgdGhhbiB0aGUgYnVuZGxlJ3MgDQogIGNyZWF0aW9uIHRp bWUgcGx1cyBpdHMgbGlmZXRpbWUgYXMgc3BlY2lmaWVkIGluIHRoZSBwcmltYXJ5IGJ1bmRsZSAN CiAgYmxvY2suICBCdW5kbGUgZXhwaXJhdGlvbiBtYXkgb2NjdXIgYXQgYW55IHBvaW50IGluIHRo ZSBwcm9jZXNzaW5nIG9mIA0KICBhIGJ1bmRsZS4gIFdoZW4gYSBidW5kbGUgZXhwaXJlcywgdGhl IGJ1bmRsZSBwcm90b2NvbCBhZ2VudCBtdXN0IA0KICBkZWxldGUgdGhlIGJ1bmRsZSBmb3IgdGhl IHJlYXNvbiAibGlmZXRpbWUgZXhwaXJlZCI6IHRoZSBidW5kbGUgDQogIGRlbGV0aW9uIHByb2Nl ZHVyZSBkZWZpbmVkIGluIDQuMTMgbXVzdCBiZSBmb2xsb3dlZC4gDQogICANCjQuNiBCdW5kbGUg cmVjZXB0aW9uIA0KICAgDQogIFRoZSBzdGVwcyBpbiBwcm9jZXNzaW5nIGEgYnVuZGxlIHJlY2Vp dmVkIGZyb20gYW5vdGhlciBub2RlIGFyZTogDQogICANCiAgU3RlcCAxOiBUaGUgcmV0ZW50aW9u IGNvbnN0cmFpbnQgIkRpc3BhdGNoIHBlbmRpbmciIG11c3QgYmUgYWRkZWQgdG8gDQogIHRoZSBi dW5kbGUuIA0KICAgDQogIFN0ZXAgMjogSWYgdGhlICJyZXF1ZXN0IHJlcG9ydGluZyBvZiBidW5k bGUgcmVjZXB0aW9uIiBmbGFnIGluIHRoZSANCiAgYnVuZGxlJ3Mgc3RhdHVzIHJlcG9ydCByZXF1 ZXN0IGZpZWxkIGlzIHNldCB0byAxLCB0aGVuIGEgYnVuZGxlIA0KICByZWNlcHRpb24gc3RhdHVz IHJlcG9ydCB3aXRoIHJlYXNvbiBjb2RlICJObyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIiANCiAg c2hvdWxkIGJlIGdlbmVyYXRlZCwgZGVzdGluZWQgZm9yIHRoZSBidW5kbGUncyByZXBvcnQtdG8g ZW5kcG9pbnQgSUQuIA0KICAgDQogIFN0ZXAgMzogRm9yIGVhY2ggYmxvY2sgaW4gdGhlIGJ1bmRs ZSB0aGF0IGlzIGFuIGV4dGVuc2lvbiBibG9jayB0aGF0IA0KICB0aGUgYnVuZGxlIHByb3RvY29s IGFnZW50IGNhbm5vdCBwcm9jZXNzOiANCiAgIA0KICAgbyBJZiB0aGUgYmxvY2sgcHJvY2Vzc2lu ZyBmbGFncyBpbiB0aGF0IGJsb2NrIGluZGljYXRlIHRoYXQgYSBzdGF0dXMgDQogIHJlcG9ydCBp cyByZXF1ZXN0ZWQgaW4gdGhpcyBldmVudCwgdGhlbiBhIGJ1bmRsZSByZWNlcHRpb24gc3RhdHVz IA0KIA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJlcyAtIFNlcHRlbWJl ciAyMDA3ICAgIFtQYWdlIDI0XSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1bmRsZSBQcm90b2Nv bCBTcGVjaWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCiAgcmVwb3J0IHdpdGgg cmVhc29uIGNvZGUgIkJsb2NrIHVuaW50ZWxsaWdpYmxlIiBzaG91bGQgYmUgZ2VuZXJhdGVkLCAN CiAgZGVzdGluZWQgZm9yIHRoZSBidW5kbGUncyByZXBvcnQtdG8gZW5kcG9pbnQgSUQuIA0KICAg DQogICBvIElmIHRoZSBibG9jayBwcm9jZXNzaW5nIGZsYWdzIGluIHRoYXQgYmxvY2sgaW5kaWNh dGUgdGhhdCB0aGUgDQogIGJ1bmRsZSBtdXN0IGJlIGRlbGV0ZWQgaW4gdGhpcyBldmVudCwgdGhl biB0aGUgYnVuZGxlIHByb3RvY29sIGFnZW50IA0KICBtdXN0IGRlbGV0ZSB0aGUgYnVuZGxlIGZv ciB0aGUgcmVhc29uICJCbG9jayB1bmludGVsbGlnaWJsZSI7IHRoZSANCiAgYnVuZGxlIGRlbGV0 aW9uIHByb2NlZHVyZSBkZWZpbmVkIGluIDQuMTMgbXVzdCBiZSBmb2xsb3dlZCBhbmQgYWxsIA0K ICByZW1haW5pbmcgc3RlcHMgb2YgdGhlIGJ1bmRsZSByZWNlcHRpb24gcHJvY2VkdXJlIG11c3Qg YmUgc2tpcHBlZC4gDQogICANCiAgIG8gSWYgdGhlIGJsb2NrIHByb2Nlc3NpbmcgZmxhZ3MgaW4g dGhhdCBibG9jayBkbyBOT1QgaW5kaWNhdGUgdGhhdCANCiAgdGhlIGJ1bmRsZSBtdXN0IGJlIGRl bGV0ZWQgaW4gdGhpcyBldmVudCBidXQgZG8gaW5kaWNhdGUgdGhhdCB0aGUgDQogIGJsb2NrIG11 c3QgYmUgZGlzY2FyZGVkLCB0aGVuIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgbXVzdCByZW1v dmUgDQogIHRoaXMgYmxvY2sgZnJvbSB0aGUgYnVuZGxlLiANCiAgIA0KICAgbyBJZiB0aGUgYmxv Y2sgcHJvY2Vzc2luZyBmbGFncyBpbiB0aGF0IGJsb2NrIGluZGljYXRlIE5FSVRIRVIgdGhhdCAN CiAgdGhlIGJ1bmRsZSBtdXN0IGJlIGRlbGV0ZWQgTk9SIHRoYXQgdGhlIGJsb2NrIG11c3QgYmUg ZGlzY2FyZGVkLCB0aGVuIA0KICB0aGUgYnVuZGxlIHByb3RvY29sIGFnZW50IG11c3Qgc2V0IHRv IDEgdGhlICJCbG9jayB3YXMgZm9yd2FyZGVkIA0KICB3aXRob3V0IGJlaW5nIHByb2Nlc3NlZCIg ZmxhZyBpbiB0aGUgYmxvY2sgcHJvY2Vzc2luZyBmbGFncyBvZiB0aGUgDQogIGJsb2NrLiANCiAg IA0KICBTdGVwIDQ6IElmIHRoZSBidW5kbGUncyBjdXN0b2R5IHRyYW5zZmVyIHJlcXVlc3RlZCBm bGFnIChpbiB0aGUgDQogIGJ1bmRsZSBwcm9jZXNzaW5nIGZsYWdzIGZpZWxkKSBpcyBzZXQgdG8g MSBhbmQgdGhlIGJ1bmRsZSBoYXMgdGhlIA0KICBzYW1lIHNvdXJjZSBlbmRwb2ludCBJRCwgY3Jl YXRpb24gdGltZXN0YW1wLCBhbmQgKGlmIHRoZSBidW5kbGUgaXMgYSANCiAgZnJhZ21lbnQpIGZy YWdtZW50IG9mZnNldCBhbmQgcGF5bG9hZCBsZW5ndGggYXMgYW5vdGhlciBidW5kbGUgdGhhdCAN CiAgKGEpIGhhcyBub3QgYmVlbiBkaXNjYXJkZWQgYW5kIChiKSBjdXJyZW50bHkgaGFzIHRoZSBy ZXRlbnRpb24gDQogIGNvbnN0cmFpbnQgIkN1c3RvZHkgYWNjZXB0ZWQiLCBjdXN0b2R5IHRyYW5z ZmVyIHJlZHVuZGFuY3kgbXVzdCBiZSANCiAgaGFuZGxlZDsgb3RoZXJ3aXNlLCBwcm9jZXNzaW5n IHByb2NlZWRzIGZyb20gU3RlcCA1LiAgUHJvY2VkdXJlcyBmb3IgDQogIGhhbmRsaW5nIHJlZHVu ZGFuY3kgaW4gY3VzdG9keSB0cmFuc2ZlciBmb3IgYSBidW5kbGUgd2hvc2UgDQogIGRlc3RpbmF0 aW9uIGlzIG5vdCBhIHNpbmdsZXRvbiBlbmRwb2ludCBhcmUgbm90IGRlZmluZWQgaW4gdGhpcyAN CiAgc3BlY2lmaWNhdGlvbi4gIEZvciBhIGJ1bmRsZSB3aG9zZSBkZXN0aW5hdGlvbiBpcyBhIHNp bmdsZXRvbiANCiAgZW5kcG9pbnQsIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgbXVzdCBoYW5k bGUgY3VzdG9keSB0cmFuc2ZlciANCiAgcmVkdW5kYW5jeSBieSBnZW5lcmF0aW5nIGEgIkZhaWxl ZCIgY3VzdG9keSBzaWduYWwgZm9yIHRoaXMgYnVuZGxlIA0KICB3aXRoIHJlYXNvbiBjb2RlICJS ZWR1bmRhbnQgcmVjZXB0aW9uIiwgZGVzdGluZWQgZm9yIHRoaXMgYnVuZGxlJ3MgDQogIGN1cnJl bnQgY3VzdG9kaWFuLCBhbmQgcmVtb3ZpbmcgdGhpcyBidW5kbGUncyAiRGlzcGF0Y2ggcGVuZGlu ZyIgDQogIHJldGVudGlvbiBjb25zdHJhaW50LiANCiAgIA0KICBTdGVwIDU6IFByb2Nlc3Npbmcg cHJvY2VlZHMgZnJvbSBTdGVwIDEgb2Ygc2VjdGlvbiA0LjMuIA0KICAgDQo0LjcgTG9jYWwgYnVu ZGxlIGRlbGl2ZXJ5IA0KICAgICANCiAgVGhlIHN0ZXBzIGluIHByb2Nlc3NpbmcgYSBidW5kbGUg dGhhdCBpcyBkZXN0aW5lZCBmb3IgYW4gZW5kcG9pbnQgb2YgDQogIHdoaWNoIHRoaXMgbm9kZSBp cyBhIG1lbWJlciBhcmU6IA0KICAgDQogIFN0ZXAgMTogSWYgdGhlIHJlY2VpdmVkIGJ1bmRsZSBp cyBhIGZyYWdtZW50LCB0aGUgYXBwbGljYXRpb24gZGF0YSANCiAgdW5pdCByZWFzc2VtYmx5IHBy b2NlZHVyZSBkZXNjcmliZWQgaW4gNC45IG11c3QgYmUgZm9sbG93ZWQuICBJZiB0aGlzIA0KICBw cm9jZWR1cmUgcmVzdWx0cyBpbiByZWFzc2VtYmx5IG9mIHRoZSBlbnRpcmUgb3JpZ2luYWwgYXBw bGljYXRpb24gDQogIGRhdGEgdW5pdCwgcHJvY2Vzc2luZyBvZiB0aGlzIGJ1bmRsZSAod2hvc2Ug ZnJhZ21lbnRhcnkgcGF5bG9hZCBoYXMgDQogIGJlZW4gcmVwbGFjZWQgYnkgdGhlIHJlYXNzZW1i bGVkIGFwcGxpY2F0aW9uIGRhdGEgdW5pdCkgcHJvY2VlZHMgZnJvbSANCiAgU3RlcCAyOyBvdGhl cndpc2UgdGhlIHJldGVudGlvbiBjb25zdHJhaW50ICJSZWFzc2VtYmx5IHBlbmRpbmciIG11c3Qg DQogIGJlIGFkZGVkIHRvIHRoZSBidW5kbGUgYW5kIGFsbCByZW1haW5pbmcgc3RlcHMgb2YgdGhp cyBwcm9jZWR1cmUgYXJlIA0KICBza2lwcGVkLiANCiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJs ZWlnaCAgICAgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwNyAgICBbUGFnZSAyNV0gDQoMSW50ZXJu ZXQgRHJhZnQgICAgICBCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNo IDIwMDcgDQogDQogDQogICANCiAgU3RlcCAyOiBEZWxpdmVyeSBkZXBlbmRzIG9uIHRoZSBzdGF0 ZSBvZiB0aGUgcmVnaXN0cmF0aW9uIHdob3NlIA0KICBlbmRwb2ludCBJRCBtYXRjaGVzIHRoYXQg b2YgdGhlIGRlc3RpbmF0aW9uIG9mIHRoZSBidW5kbGU6IA0KICAgDQogICBvIElmIHRoZSByZWdp c3RyYXRpb24gaXMgaW4gdGhlIEFjdGl2ZSBzdGF0ZSwgdGhlbiB0aGUgYnVuZGxlIG11c3QgDQog IGJlIGRlbGl2ZXJlZCBzdWJqZWN0IHRvIHRoaXMgcmVnaXN0cmF0aW9uIChzZWUgMi4xIGFib3Zl KSBhcyBzb29uIGFzIA0KICBhbGwgcHJldmlvdXNseSByZWNlaXZlZCBidW5kbGVzIHRoYXQgYXJl IGRlbGl2ZXJhYmxlIHN1YmplY3QgdG8gdGhpcyANCiAgcmVnaXN0cmF0aW9uIGhhdmUgYmVlbiBk ZWxpdmVyZWQuIA0KICAgDQogICBvIElmIHRoZSByZWdpc3RyYXRpb24gaXMgaW4gdGhlIFBhc3Np dmUgc3RhdGUsIHRoZW4gdGhlIA0KICByZWdpc3RyYXRpb24ncyBkZWxpdmVyeSBmYWlsdXJlIGFj dGlvbiBtdXN0IGJlIHRha2VuIChzZWUgMi4xIGFib3ZlKS4gDQogICANCiAgU3RlcCAzOiBBcyBz b29uIGFzIHRoZSBidW5kbGUgaGFzIGJlZW4gZGVsaXZlcmVkOiANCiAgIA0KICAgbyBJZiB0aGUg InJlcXVlc3QgcmVwb3J0aW5nIG9mIGJ1bmRsZSBkZWxpdmVyeSIgZmxhZyBpbiB0aGUgYnVuZGxl J3MgDQogIHN0YXR1cyByZXBvcnQgcmVxdWVzdCBmaWVsZCBpcyBzZXQgdG8gMSwgdGhlbiBhIGJ1 bmRsZSBkZWxpdmVyeSANCiAgc3RhdHVzIHJlcG9ydCBzaG91bGQgYmUgZ2VuZXJhdGVkLCBkZXN0 aW5lZCBmb3IgdGhlIGJ1bmRsZSdzIHJlcG9ydC0NCiAgdG8gZW5kcG9pbnQgSUQuICBOb3RlIHRo YXQgdGhpcyBzdGF0dXMgcmVwb3J0IG9ubHkgc3RhdGVzIHRoYXQgdGhlIA0KICBwYXlsb2FkIGhh cyBiZWVuIGRlbGl2ZXJlZCB0byB0aGUgYXBwbGljYXRpb24gYWdlbnQsIG5vdCB0aGF0IHRoZSAN CiAgYXBwbGljYXRpb24gYWdlbnQgaGFzIHByb2Nlc3NlZCB0aGF0IHBheWxvYWQuIA0KICAgDQog ICBvIElmIHRoZSBidW5kbGUncyBjdXN0b2R5IHRyYW5zZmVyIHJlcXVlc3RlZCBmbGFnIChpbiB0 aGUgYnVuZGxlIA0KICBwcm9jZXNzaW5nIGZsYWdzIGZpZWxkKSBpcyBzZXQgdG8gMSwgY3VzdG9k aWFsIGRlbGl2ZXJ5IG11c3QgYmUgDQogIHJlcG9ydGVkLiAgUHJvY2VkdXJlcyBmb3IgcmVwb3J0 aW5nIGN1c3RvZGlhbCBkZWxpdmVyeSBmb3IgYSBidW5kbGUgDQogIHdob3NlIGRlc3RpbmF0aW9u IGlzIG5vdCBhIHNpbmdsZXRvbiBlbmRwb2ludCBhcmUgbm90IGRlZmluZWQgaW4gdGhpcyANCiAg c3BlY2lmaWNhdGlvbi4gIEZvciBhIGJ1bmRsZSB3aG9zZSBkZXN0aW5hdGlvbiBpcyBhIHNpbmds ZXRvbiANCiAgZW5kcG9pbnQsIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgbXVzdCByZXBvcnQg Y3VzdG9kaWFsIGRlbGl2ZXJ5IGJ5IA0KICBnZW5lcmF0aW5nIGEgIlN1Y2NlZWRlZCIgY3VzdG9k eSBzaWduYWwgZm9yIHRoZSBidW5kbGUsIGRlc3RpbmVkIGZvciANCiAgdGhlIGJ1bmRsZSdzIGN1 cnJlbnQgY3VzdG9kaWFuLiANCiAgIA0KNC44ICANICAgIEJ1bmRsZSBGcmFnbWVudGF0aW9uIA0K ICAgDQogIEl0IG1heSBhdCB0aW1lcyBiZSBuZWNlc3NhcnkgZm9yIGJ1bmRsZSBwcm90b2NvbCBh Z2VudHMgdG8gcmVkdWNlIHRoZSANCiAgc2l6ZXMgb2YgYnVuZGxlcyBpbiBvcmRlciB0byBmb3J3 YXJkIHRoZW0uICBUaGlzIG1pZ2h0IGJlIHRoZSBjYXNlLCANCiAgZm9yIGV4YW1wbGUsIGlmIHRo ZSBlbmRwb2ludCB0byB3aGljaCBhIGJ1bmRsZSBpcyB0byBiZSBmb3J3YXJkZWQgaXMgDQogIGFj Y2Vzc2libGUgb25seSB2aWEgaW50ZXJtaXR0ZW50IGNvbnRhY3RzIGFuZCBubyB1cGNvbWluZyBj b250YWN0IGlzIA0KICBsb25nIGVub3VnaCB0byBlbmFibGUgdGhlIGZvcndhcmRpbmcgb2YgdGhl IGVudGlyZSBidW5kbGUuIA0KICAgDQogIFRoZSBzaXplIG9mIGEgYnVuZGxlIGNhbiBiZSByZWR1 Y2VkIGJ5ICJmcmFnbWVudGluZyIgdGhlIGJ1bmRsZS4gIFRvIA0KICBmcmFnbWVudCBhIGJ1bmRs ZSB3aG9zZSBwYXlsb2FkIGlzIG9mIHNpemUgTSBpcyB0byByZXBsYWNlIGl0IHdpdGggDQogIHR3 byAiZnJhZ21lbnRzIiAtIG5ldyBidW5kbGVzIHdpdGggdGhlIHNhbWUgc291cmNlIGVuZHBvaW50 IElEIGFuZCANCiAgY3JlYXRpb24gdGltZXN0YW1wIGFzIHRoZSBvcmlnaW5hbCBidW5kbGUgLSB3 aG9zZSBwYXlsb2FkcyBhcmUgdGhlIA0KICBmaXJzdCBOIGFuZCB0aGUgbGFzdCAoTSAtIE4pIGJ5 dGVzIG9mIHRoZSBvcmlnaW5hbCBidW5kbGUncyBwYXlsb2FkLCANCiAgd2hlcmUgMCA8IE4gPCBN LiAgTm90ZSB0aGF0IGZyYWdtZW50cyBtYXkgdGhlbXNlbHZlcyBiZSBmcmFnbWVudGVkLCANCiAg c28gZnJhZ21lbnRhdGlvbiBtYXkgaW4gZWZmZWN0IHJlcGxhY2UgdGhlIG9yaWdpbmFsIGJ1bmRs ZSB3aXRoIG1vcmUgDQogIHRoYW4gdHdvIGZyYWdtZW50cy4gIChIb3dldmVyLCB0aGVyZSBpcyBv bmx5IG9uZSAnbGV2ZWwnIG9mIA0KICBmcmFnbWVudGF0aW9uLCBhcyBpbiBJUCBmcmFnbWVudGF0 aW9uLikgDQogICANCiAgQW55IGJ1bmRsZSB3aG9zZSBwcmltYXJ5IGJsb2NrJ3MgYnVuZGxlIHBy b2Nlc3NpbmcgZmxhZ3MgZG8gTk9UIA0KICBpbmRpY2F0ZSB0aGF0IGl0IG11c3Qgbm90IGJlIGZy YWdtZW50ZWQgbWF5IGJlIGZyYWdtZW50ZWQgYXQgYW55IA0KICB0aW1lLCBmb3IgYW55IHB1cnBv c2UsIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBidW5kbGUgcHJvdG9jb2wgDQogDQogDQpLLiBT Y290dCBhbmQgUy4gQnVybGVpZ2ggICAgICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDcgICAgW1Bh Z2UgMjZdIA0KDEludGVybmV0IERyYWZ0ICAgICAgQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRp b24gICAgICAgICBNYXJjaCAyMDA3IA0KIA0KIA0KICBhZ2VudC4gDQogICANCiAgRnJhZ21lbnRh dGlvbiBzaGFsbCBiZSBjb25zdHJhaW5lZCBhcyBmb2xsb3dzOiANCiAgIA0KICBvIA0gICBUaGUg Y29uY2F0ZW5hdGlvbiBvZiB0aGUgcGF5bG9hZHMgb2YgYWxsIGZyYWdtZW50cyBwcm9kdWNlZCBi eSBhIA0KICBmcmFnbWVudGF0aW9uIG11c3QgYWx3YXlzIGJlIGlkZW50aWNhbCB0byB0aGUgcGF5 bG9hZCBvZiB0aGUgYnVuZGxlIA0KICB0aGF0IHdhcyBmcmFnbWVudGVkLiAgTm90ZSB0aGF0IHRo ZSBwYXlsb2FkcyBvZiBmcmFnbWVudHMgcmVzdWx0aW5nIA0KICBmcm9tIGRpZmZlcmVudCBmcmFn bWVudGF0aW9uIGVwaXNvZGVzLCBpbiBkaWZmZXJlbnQgcGFydHMgb2YgdGhlIA0KICBuZXR3b3Jr LCBtYXkgYmUgb3ZlcmxhcHBpbmcgc3Vic2V0cyBvZiB0aGUgb3JpZ2luYWwgYnVuZGxlJ3MgcGF5 bG9hZC4gDQogICANCiAgbyANICAgVGhlIGJ1bmRsZSBwcm9jZXNzaW5nIGZsYWdzIGluIHRoZSBw cmltYXJ5IGJsb2NrIG9mIGVhY2ggZnJhZ21lbnQgDQogIG11c3QgYmUgbW9kaWZpZWQgdG8gaW5k aWNhdGUgdGhhdCB0aGUgYnVuZGxlIGlzIGEgZnJhZ21lbnQsIGFuZCBib3RoIA0KICBmcmFnbWVu dCBvZmZzZXQgYW5kIHRvdGFsIGFwcGxpY2F0aW9uIGRhdGEgdW5pdCBsZW5ndGggbXVzdCBiZSAN CiAgcHJvdmlkZWQgYXQgdGhlIGVuZCBvZiBlYWNoIGZyYWdtZW50J3MgcHJpbWFyeSBidW5kbGUg YmxvY2suIA0KICAgDQogICBvIEFsbCBmcmFnbWVudHMgbXVzdCBjb250YWluIHRoZSBzYW1lIGJs b2NrcyBhcyB0aGUgb3JpZ2luYWwgYnVuZGxlLCANCiAgZXhjZXB0IHRoYXQgKGEpIHRoZSBwcmlt YXJ5IGJsb2NrcyBvZiB0aGUgZnJhZ21lbnRzIHdpbGwgZGlmZmVyIGZyb20gDQogIHRoYXQgb2Yg dGhlIGZyYWdtZW50ZWQgYnVuZGxlIGFzIG5vdGVkIGFib3ZlLCAoYikgdGhlIHBheWxvYWQgYmxv Y2tzIA0KICBvZiBmcmFnbWVudHMgd2lsbCBkaWZmZXIgZnJvbSB0aGF0IG9mIHRoZSBmcmFnbWVu dGVkIGJ1bmRsZSwgYW5kIChjKSANCiAgYW55IGJsb2NrIHdob3NlIGJsb2NrIHByb2Nlc3Npbmcg ZmxhZ3MgZG8gTk9UIGluZGljYXRlIHRoYXQgdGhlIGJsb2NrIA0KICBtdXN0IGJlIHJlcGxpY2F0 ZWQgaW4gZXZlcnkgZnJhZ21lbnQgbXVzdCBiZSByZXBsaWNhdGVkIGluIG9uZSBvZiB0aGUgDQog IGZyYWdtZW50cyBhbmQgc2hvdWxkIGJlIHJlcGxpY2F0ZWQgb25seSBpbiB0aGUgZnJhZ21lbnQg d2hvc2UgDQogIGZyYWdtZW50IG9mZnNldCBpcyB6ZXJvLiANCiAgIA0KNC45IEFwcGxpY2F0aW9u IERhdGEgVW5pdCBSZWFzc2VtYmx5IA0KICAgDQogIElmIHRoZSBjb25jYXRlbmF0aW9uIC0gYXMg aW5mb3JtZWQgYnkgZnJhZ21lbnQgb2Zmc2V0cyBhbmQgcGF5bG9hZCANCiAgbGVuZ3RocyAtIG9m IHRoZSBwYXlsb2FkcyBvZiBhbGwgcHJldmlvdXNseSByZWNlaXZlZCBmcmFnbWVudHMgd2l0aCAN CiAgdGhlIHNhbWUgc291cmNlIGVuZHBvaW50IElEIGFuZCBjcmVhdGlvbiB0aW1lc3RhbXAgYXMg dGhpcyBmcmFnbWVudCwgDQogIHRvZ2V0aGVyIHdpdGggdGhlIHBheWxvYWQgb2YgdGhpcyBmcmFn bWVudCwgZm9ybXMgYSBieXRlIGFycmF5IHdob3NlIA0KICBsZW5ndGggaXMgZXF1YWwgdG8gdGhl IHRvdGFsIGFwcGxpY2F0aW9uIGRhdGEgdW5pdCBsZW5ndGggaW4gdGhlIA0KICBmcmFnbWVudCdz IHByaW1hcnkgYmxvY2ssIHRoZW46IA0KICAgDQogIG8gDSAgIFRoaXMgYnl0ZSBhcnJheSAtIHRo ZSByZWFzc2VtYmxlZCBhcHBsaWNhdGlvbiBkYXRhIHVuaXQgLSBtdXN0IA0KICByZXBsYWNlIHRo ZSBwYXlsb2FkIG9mIHRoaXMgZnJhZ21lbnQuIA0KICAgDQogIG8gDSAgIFRoZSAiUmVhc3NlbWJs eSBwZW5kaW5nIiByZXRlbnRpb24gY29uc3RyYWludCBtdXN0IGJlIHJlbW92ZWQgZnJvbSANCiAg ZXZlcnkgb3RoZXIgZnJhZ21lbnQgd2hvc2UgcGF5bG9hZCBpcyBhIHN1YnNldCBvZiB0aGUgcmVh c3NlbWJsZWQgDQogIGFwcGxpY2F0aW9uIGRhdGEgdW5pdC4gDQogICANCiAgTm90ZTogcmVhc3Nl bWJseSBvZiBhcHBsaWNhdGlvbiBkYXRhIHVuaXRzIGZyb20gZnJhZ21lbnRzIG9jY3VycyBhdCAN CiAgZGVzdGluYXRpb24gZW5kcG9pbnRzIGFzIG5lY2Vzc2FyeTsgYW4gYXBwbGljYXRpb24gZGF0 YSB1bml0IG1heSBhbHNvIA0KICBiZSByZWFzc2VtYmxlZCBhdCBzb21lIG90aGVyIGVuZHBvaW50 IG9uIHRoZSByb3V0ZSB0byB0aGUgDQogIGRlc3RpbmF0aW9uLiANCiAgIA0KNC4xMCBDdXN0b2R5 IHRyYW5zZmVyIA0KICAgDQogIFRoZSBjb25kaXRpb25zIHVuZGVyIHdoaWNoIGEgbm9kZSBtYXkg YWNjZXB0IGN1c3RvZHkgb2YgYSBidW5kbGUgDQogIHdob3NlIGRlc3RpbmF0aW9uIGlzIG5vdCBh IHNpbmdsZXRvbiBlbmRwb2ludCBhcmUgbm90IGRlZmluZWQgaW4gdGhpcyANCiAgc3BlY2lmaWNh dGlvbi4gDQogICANCiANCgwgDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAgICBFeHBpcmVz IC0gU2VwdGVtYmVyIDIwMDcgICAgW1BhZ2UgMjddIA0KDEludGVybmV0IERyYWZ0ICAgICAgQnVu ZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0KIA0KIA0KICBU aGUgZGVjaXNpb24gYXMgdG8gd2hldGhlciBvciBub3QgdG8gYWNjZXB0IGN1c3RvZHkgb2YgYSBi dW5kbGUgd2hvc2UgDQogIGRlc3RpbmF0aW9uIGlzIGEgc2luZ2xldG9uIGVuZHBvaW50IGlzIGFu IGltcGxlbWVudGF0aW9uIG1hdHRlciB3aGljaCANCiAgbWF5IGludm9sdmUgYm90aCByZXNvdXJj ZSBhbmQgcG9saWN5IGNvbnNpZGVyYXRpb25zOyBob3dldmVyLCBpZiB0aGUgDQogIGJ1bmRsZSBw cm90b2NvbCBhZ2VudCBoYXMgY29tbWl0dGVkIHRvIGFjY2VwdGluZyBjdXN0b2R5IG9mIHRoZSAN CiAgYnVuZGxlIChhcyBkZXNjcmliZWQgaW4gU3RlcCAxIG9mIDQuMikgdGhlbiBjdXN0b2R5IG11 c3QgYmUgYWNjZXB0ZWQuIA0KICAgDQogIElmIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgZWxl Y3RzIHRvIGFjY2VwdCBjdXN0b2R5IG9mIHRoZSBidW5kbGUsIA0KICB0aGVuIGl0IG11c3QgZm9s bG93IHRoZSBjdXN0b2R5IGFjY2VwdGFuY2UgcHJvY2VkdXJlIGRlZmluZWQgaW4gDQogIDQuMTAu MS4gDQogICANCjQuMTAuMSANICAgICAgIEN1c3RvZHkgYWNjZXB0YW5jZSANCiAgIA0KICBQcm9j ZWR1cmVzIGZvciBhY2NlcHRhbmNlIG9mIGN1c3RvZHkgb2YgYSBidW5kbGUgd2hvc2UgZGVzdGlu YXRpb24gaXMgDQogIG5vdCBhIHNpbmdsZXRvbiBlbmRwb2ludCBhcmUgbm90IGRlZmluZWQgaW4g dGhpcyBzcGVjaWZpY2F0aW9uLiANCiAgIA0KICBQcm9jZWR1cmVzIGZvciBhY2NlcHRhbmNlIG9m IGN1c3RvZHkgb2YgYSBidW5kbGUgd2hvc2UgZGVzdGluYXRpb24gaXMgDQogIGEgc2luZ2xldG9u IGVuZHBvaW50IGFyZSBkZWZpbmVkIGFzIGZvbGxvd3MuIA0KICAgDQogIFRoZSByZXRlbnRpb24g Y29uc3RyYWludCAiQ3VzdG9keSBhY2NlcHRlZCIgbXVzdCBiZSBhZGRlZCB0byB0aGUgDQogIGJ1 bmRsZS4gDQogICANCiAgSWYgdGhlICJyZXF1ZXN0IGN1c3RvZHkgYWNjZXB0YW5jZSByZXBvcnRp bmciIGZsYWcgaW4gdGhlIGJ1bmRsZSdzIA0KICBzdGF0dXMgcmVwb3J0IHJlcXVlc3QgZmllbGQg aXMgc2V0IHRvIDEsIGEgY3VzdG9keSBhY2NlcHRhbmNlIHN0YXR1cyANCiAgcmVwb3J0IHNob3Vs ZCBiZSBnZW5lcmF0ZWQsIGRlc3RpbmVkIGZvciB0aGUgcmVwb3J0LXRvIGVuZHBvaW50IElEIG9m IA0KICB0aGUgYnVuZGxlLiAgSG93ZXZlciwgaWYgYSBidW5kbGUgcmVjZXB0aW9uIHN0YXR1cyBy ZXBvcnQgd2FzIA0KICBnZW5lcmF0ZWQgZm9yIHRoaXMgYnVuZGxlIChzdGVwIDEgb2YgNC42KSB0 aGVuIHRoaXMgcmVwb3J0IHNob3VsZCBiZSANCiAgZ2VuZXJhdGVkIGJ5IHNpbXBseSB0dXJuaW5n IG9uIHRoZSAiUmVwb3J0aW5nIG5vZGUgYWNjZXB0ZWQgY3VzdG9keSANCiAgb2YgYnVuZGxlIiBm bGFnIGluIHRoYXQgZWFybGllciByZXBvcnQncyBzdGF0dXMgZmxhZ3MgYnl0ZS4gIA0KICAgDQog IFRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgbXVzdCBnZW5lcmF0ZSBhICJTdWNjZWVkZWQiIGN1 c3RvZHkgc2lnbmFsIA0KICBmb3IgdGhlIGJ1bmRsZSwgZGVzdGluZWQgZm9yIHRoZSBidW5kbGUn cyBjdXJyZW50IGN1c3RvZGlhbi4gDQogICANCiAgVGhlIGJ1bmRsZSBwcm90b2NvbCBhZ2VudCBt dXN0IGFzc2VydCB0aGUgbmV3IGN1cnJlbnQgY3VzdG9kaWFuIGZvciANCiAgdGhlIGJ1bmRsZS4g IEl0IGRvZXMgc28gYnkgY2hhbmdpbmcgdGhlIGN1cnJlbnQgY3VzdG9kaWFuIGVuZHBvaW50IElE IA0KICBpbiB0aGUgYnVuZGxlJ3MgcHJpbWFyeSBibG9jayB0byB0aGUgZW5kcG9pbnQgSUQgb2Yg b25lIG9mIHRoZSANCiAgc2luZ2xldG9uIGVuZHBvaW50cyBpbiB3aGljaCB0aGUgbm9kZSBpcyBy ZWdpc3RlcmVkLiAgVGhpcyBtYXkgZW50YWlsIA0KICBhcHBlbmRpbmcgdGhhdCBlbmRwb2ludCBJ RCdzIG51bGwtdGVybWluYXRlZCBzY2hlbWUgbmFtZSBhbmQgU1NQIHRvIA0KICB0aGUgZGljdGlv bmFyeSBieXRlIGFycmF5IGluIHRoZSBidW5kbGUncyBwcmltYXJ5IGJsb2NrLCBhbmQgaW4gc29t ZSANCiAgY2FzZSBpdCBtYXkgYWxzbyBlbmFibGUgdGhlIChvcHRpb25hbCkgcmVtb3ZhbCBvZiB0 aGUgY3VycmVudCANCiAgY3VzdG9kaWFuIGVuZHBvaW50IElEJ3Mgc2NoZW1lIG5hbWUgYW5kL29y IFNTUCBmcm9tIHRoZSBkaWN0aW9uYXJ5LiANCiAgIA0KICBUaGUgYnVuZGxlIHByb3RvY29sIGFn ZW50IG1heSBzZXQgYSBjdXN0b2R5IHRyYW5zZmVyIGNvdW50ZG93biB0aW1lciANCiAgZm9yIHRo aXMgYnVuZGxlOyB1cG9uIGV4cGlyYXRpb24gb2YgdGhpcyB0aW1lciBwcmlvciB0byBleHBpcmF0 aW9uIG9mIA0KICB0aGUgYnVuZGxlIGl0c2VsZiBhbmQgcHJpb3IgdG8gY3VzdG9keSB0cmFuc2Zl ciBzdWNjZXNzIGZvciB0aGlzIA0KICBidW5kbGUsIHRoZSBjdXN0b2R5IHRyYW5zZmVyIGZhaWx1 cmUgcHJvY2VkdXJlIGRldGFpbGVkIGluIHNlY3Rpb24gDQogIDQuMTIgbXVzdCBiZSBmb2xsb3dl ZC4gIFRoZSBtYW5uZXIgaW4gd2hpY2ggdGhlIGNvdW50ZG93biBpbnRlcnZhbCANCiAgZm9yIHN1 Y2ggYSB0aW1lciBpcyBkZXRlcm1pbmVkIGlzIGFuIGltcGxlbWVudGF0aW9uIG1hdHRlci4gDQog ICANCiAgVGhlIGJ1bmRsZSBzaG91bGQgYmUgcmV0YWluZWQgaW4gcGVyc2lzdGVudCBzdG9yYWdl IGlmIHBvc3NpYmxlLiANCiAgIA0KDQogDQogDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAg ICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDcgICAgW1BhZ2UgMjhdIA0KDEludGVybmV0IERyYWZ0 ICAgICAgQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0K IA0KIA0KNC4xMC4yIA0gICAgICAgQ3VzdG9keSByZWxlYXNlIA0KICAgDQogIFByb2NlZHVyZXMg Zm9yIHJlbGVhc2Ugb2YgY3VzdG9keSBvZiBhIGJ1bmRsZSB3aG9zZSBkZXN0aW5hdGlvbiBpcyAN CiAgbm90IGEgc2luZ2xldG9uIGVuZHBvaW50IGFyZSBub3QgZGVmaW5lZCBpbiB0aGlzIHNwZWNp ZmljYXRpb24uIA0KICAgDQogIFdoZW4gY3VzdG9keSBvZiBhIGJ1bmRsZSBpcyByZWxlYXNlZCwg d2hlcmUgdGhlIGRlc3RpbmF0aW9uIG9mIHRoZSANCiAgYnVuZGxlIGlzIGEgc2luZ2xldG9uIGVu ZHBvaW50LCB0aGUgIkN1c3RvZHkgYWNjZXB0ZWQiIHJldGVudGlvbiANCiAgY29uc3RyYWludCBt dXN0IGJlIHJlbW92ZWQgZnJvbSB0aGUgYnVuZGxlIGFuZCBhbnkgY3VzdG9keSB0cmFuc2ZlciAN CiAgdGltZXIgdGhhdCBoYXMgYmVlbiBlc3RhYmxpc2hlZCBmb3IgdGhpcyBidW5kbGUgbXVzdCBi ZSBkZXN0cm95ZWQuIA0KICAgDQo0LjExIEN1c3RvZHkgdHJhbnNmZXIgc3VjY2VzcyANCiAgIA0K ICBQcm9jZWR1cmVzIGZvciBkZXRlcm1pbmluZyBjdXN0b2R5IHRyYW5zZmVyIHN1Y2Nlc3MgZm9y IGEgYnVuZGxlIA0KICB3aG9zZSBkZXN0aW5hdGlvbiBpcyBub3QgYSBzaW5nbGV0b24gZW5kcG9p bnQgYXJlIG5vdCBkZWZpbmVkIGluIHRoaXMgDQogIHNwZWNpZmljYXRpb24uIA0KICAgDQogIFVw b24gcmVjZWlwdCBvZiBhICJTdWNjZWVkZWQiIGN1c3RvZHkgc2lnbmFsIGF0IGEgbm9kZSB0aGF0 IGlzIGEgDQogIGN1c3RvZGlhbCBub2RlIG9mIHRoZSBidW5kbGUgaWRlbnRpZmllZCBpbiB0aGUg Y3VzdG9keSBzaWduYWwsIHdoZXJlIA0KICB0aGUgZGVzdGluYXRpb24gb2YgdGhlIGJ1bmRsZSBp cyBhIHNpbmdsZXRvbiBlbmRwb2ludCwgY3VzdG9keSBvZiB0aGUgDQogIGJ1bmRsZSBtdXN0IGJl IHJlbGVhc2VkIGFzIGRlc2NyaWJlZCBpbiA0LjEwLjIuIA0KICAgDQo0LjEyIEN1c3RvZHkgdHJh bnNmZXIgZmFpbHVyZSANCiAgIA0KICBQcm9jZWR1cmVzIGZvciBkZXRlcm1pbmluZyBjdXN0b2R5 IHRyYW5zZmVyIGZhaWx1cmUgZm9yIGEgYnVuZGxlIA0KICB3aG9zZSBkZXN0aW5hdGlvbiBpcyBu b3QgYSBzaW5nbGV0b24gZW5kcG9pbnQgYXJlIG5vdCBkZWZpbmVkIGluIHRoaXMgDQogIHNwZWNp ZmljYXRpb24uICBDdXN0b2R5IHRyYW5zZmVyIGZvciBhIGJ1bmRsZSB3aG9zZSBkZXN0aW5hdGlv biBpcyBhIA0KICBzaW5nbGV0b24gZW5kcG9pbnQgaXMgZGV0ZXJtaW5lZCB0byBoYXZlIGZhaWxl ZCBhdCBhIGN1c3RvZGlhbCBub2RlIA0KICBmb3IgdGhhdCBidW5kbGUgd2hlbiBlaXRoZXIgKGEp IHRoYXQgbm9kZSdzIGN1c3RvZHkgdHJhbnNmZXIgdGltZXIgDQogIGZvciB0aGF0IGJ1bmRsZSAo aWYgYW55KSBleHBpcmVzIG9yIChiKSBhICJGYWlsZWQiIGN1c3RvZHkgc2lnbmFsIGZvciANCiAg dGhhdCBidW5kbGUgaXMgcmVjZWl2ZWQgYXQgdGhhdCBub2RlLiAgIA0KICAgDQogIFVwb24gZGV0 ZXJtaW5hdGlvbiBvZiBjdXN0b2R5IHRyYW5zZmVyIGZhaWx1cmUsIHRoZSBhY3Rpb24gdGFrZW4g YnkgDQogIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lm aWMgYW5kIG1heSBkZXBlbmQgDQogIG9uIHRoZSBuYXR1cmUgb2YgdGhlIGZhaWx1cmUuICBGb3Ig ZXhhbXBsZSwgaWYgY3VzdG9keSB0cmFuc2ZlciANCiAgZmFpbHVyZSB3YXMgaW5mZXJyZWQgZnJv bSBleHBpcmF0aW9uIG9mIGEgY3VzdG9keSB0cmFuc2ZlciB0aW1lciBvciANCiAgd2FzIGFzc2Vy dGVkIGJ5IGEgIkZhaWxlZCIgY3VzdG9keSBzaWduYWwgd2l0aCB0aGUgIkRlcGxldGVkIHN0b3Jh Z2UiIA0KICByZWFzb24gY29kZSwgdGhlIGJ1bmRsZSBwcm90b2NvbCBhZ2VudCBtaWdodCBjaG9v c2UgdG8gcmUtZm9yd2FyZCB0aGUgDQogIGJ1bmRsZSwgcG9zc2libHkgb24gYSBkaWZmZXJlbnQg cm91dGUgKHNlY3Rpb24gNC40KS4gIFJlY2VpcHQgb2YgYSANCiAgIkZhaWxlZCIgY3VzdG9keSBz aWduYWwgd2l0aCB0aGUgIlJlZHVuZGFudCByZWNlcHRpb24iIHJlYXNvbiBjb2RlLCANCiAgb24g dGhlIG90aGVyIGhhbmQsIG1pZ2h0IGNhdXNlIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgdG8g cmVsZWFzZSANCiAgY3VzdG9keSBvZiB0aGUgYnVuZGxlIGFuZCB0byByZXZpc2UgaXRzIGFsZ29y aXRobSBmb3IgY29tcHV0aW5nIA0KICBjb3VudGRvd24gaW50ZXJ2YWxzIGZvciBjdXN0b2R5IHRy YW5zZmVyIHRpbWVycy4gDQogICANCjQuMTMgQnVuZGxlIGRlbGV0aW9uIA0KICAgDQogIFRoZSBz dGVwcyBpbiBkZWxldGluZyBhIGJ1bmRsZSBhcmU6IA0KICAgDQogIFN0ZXAgMTogSWYgdGhlIHJl dGVudGlvbiBjb25zdHJhaW50ICJDdXN0b2R5IGFjY2VwdGVkIiBjdXJyZW50bHkgDQogIHByZXZl bnRzIHRoaXMgYnVuZGxlIGZyb20gYmVpbmcgZGlzY2FyZGVkLCBhbmQgdGhlIGRlc3RpbmF0aW9u IG9mIHRoZSANCiAgYnVuZGxlIGlzIGEgc2luZ2xldG9uIGVuZHBvaW50LCB0aGVuOiANCiAgIA0K IA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJlcyAtIFNlcHRlbWJlciAy MDA3ICAgIFtQYWdlIDI5XSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1bmRsZSBQcm90b2NvbCBT cGVjaWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCiAgIG8gQ3VzdG9keSBvZiB0 aGUgbm9kZSBpcyByZWxlYXNlZCBhcyBkZXNjcmliZWQgaW4gNC4xMC4yLiANCiAgIA0KICAgbyBB IGJ1bmRsZSBkZWxldGlvbiBzdGF0dXMgcmVwb3J0IGNpdGluZyB0aGUgcmVhc29uIGZvciBkZWxl dGlvbiANCiAgbXVzdCBiZSBnZW5lcmF0ZWQsIGRlc3RpbmVkIGZvciB0aGUgYnVuZGxlJ3MgcmVw b3J0LXRvIGVuZHBvaW50IElELiANCiAgIA0KICBPdGhlcndpc2UsIGlmIHRoZSAicmVxdWVzdCBy ZXBvcnRpbmcgb2YgYnVuZGxlIGRlbGV0aW9uIiBmbGFnIGluIHRoZSANCiAgYnVuZGxlJ3Mgc3Rh dHVzIHJlcG9ydCByZXF1ZXN0IGZpZWxkIGlzIHNldCB0byAxLCB0aGVuIGEgYnVuZGxlIA0KICBk ZWxldGlvbiBzdGF0dXMgcmVwb3J0IGNpdGluZyB0aGUgcmVhc29uIGZvciBkZWxldGlvbiBzaG91 bGQgYmUgDQogIGdlbmVyYXRlZCwgZGVzdGluZWQgZm9yIHRoZSBidW5kbGUncyByZXBvcnQtdG8g ZW5kcG9pbnQgSUQuIA0KICAgDQogIFN0ZXAgMjogQWxsIG9mIHRoZSBidW5kbGUncyByZXRlbnRp b24gY29uc3RyYWludHMgbXVzdCBiZSByZW1vdmVkLiANCiAgIA0KNC4xNCBEaXNjYXJkaW5nIGEg YnVuZGxlIA0KICAgDQogIEFzIHNvb24gYXMgYSBidW5kbGUgaGFzIG5vIHJlbWFpbmluZyByZXRl bnRpb24gY29uc3RyYWludHMgaXQgbWF5IGJlIA0KICBkaXNjYXJkZWQuIA0KICAgDQo0LjE1IENh bmNlbGluZyBhIHRyYW5zbWlzc2lvbiANCiAgIA0KICBXaGVuIHJlcXVlc3RlZCB0byBjYW5jZWwg YSBzcGVjaWZpZWQgdHJhbnNtaXNzaW9uLCB3aGVyZSB0aGUgYnVuZGxlIA0KICBjcmVhdGVkIHVw b24gaW5pdGlhdGlvbiBvZiB0aGUgaW5kaWNhdGVkIHRyYW5zbWlzc2lvbiBoYXMgbm90IHlldCAN CiAgYmVlbiBkaXNjYXJkZWQsIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgbXVzdCBkZWxldGUg dGhhdCBidW5kbGUgZm9yIA0KICB0aGUgcmVhc29uICJ0cmFuc21pc3Npb24gY2FuY2VsZWQiLiAg Rm9yIHRoaXMgcHVycG9zZSwgdGhlIHByb2NlZHVyZSANCiAgZGVmaW5lZCBpbiA0LjEzIG11c3Qg YmUgZm9sbG93ZWQuIA0KICAgDQo0LjE2IFBvbGxpbmcgDQogICANCiAgV2hlbiByZXF1ZXN0ZWQg dG8gcG9sbCBhIHNwZWNpZmllZCByZWdpc3RyYXRpb24gdGhhdCBpcyBpbiBQYXNzaXZlIA0KICBz dGF0ZSwgdGhlIGJ1bmRsZSBwcm90b2NvbCBhZ2VudCBtdXN0IGltbWVkaWF0ZWx5IGRlbGl2ZXIg dGhlIGxlYXN0IA0KICByZWNlbnRseSByZWNlaXZlZCBidW5kbGUgdGhhdCBpcyBkZWxpdmVyYWJs ZSBzdWJqZWN0IHRvIHRoZSBpbmRpY2F0ZWQgDQogIHJlZ2lzdHJhdGlvbiwgaWYgYW55LiANCiAg IA0KNS4gICBBZG1pbmlzdHJhdGl2ZSByZWNvcmQgcHJvY2Vzc2luZyANCiAgIA0KNS4xIEFkbWlu aXN0cmF0aXZlIHJlY29yZHMgDQogICANCiAgIEFkbWluaXN0cmF0aXZlIHJlY29yZHMgYXJlIHN0 YW5kYXJkIGFwcGxpY2F0aW9uIGRhdGEgdW5pdHMgdGhhdCBhcmUgDQogICB1c2VkIGluIHByb3Zp ZGluZyBzb21lIG9mIHRoZSBmZWF0dXJlcyBvZiB0aGUgQnVuZGxlIFByb3RvY29sLiAgVHdvIA0K ICAgdHlwZXMgb2YgYWRtaW5pc3RyYXRpdmUgcmVjb3JkcyBoYXZlIGJlZW4gZGVmaW5lZCB0byBk YXRlOiBidW5kbGUgDQogICBzdGF0dXMgcmVwb3J0cyBhbmQgY3VzdG9keSBzaWduYWxzLiANCiAg ICANCiAgIEV2ZXJ5IGFkbWluaXN0cmF0aXZlIHJlY29yZCBjb25zaXN0cyBvZiBhIGZvdXItYml0 IHJlY29yZCB0eXBlIGNvZGUgDQogICBmb2xsb3dlZCBieSBmb3VyIGJpdHMgb2YgYWRtaW5pc3Ry YXRpdmUgcmVjb3JkIGZsYWdzLCBmb2xsb3dlZCBieSANCiAgIHJlY29yZCBjb250ZW50IGluIHR5 cGUtc3BlY2lmaWMgZm9ybWF0LiAgUmVjb3JkIHR5cGUgY29kZXMgYXJlIA0KICAgZGVmaW5lZCBh cyBmb2xsb3dzOiANCg0KDQoNCg0KDQoNCiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAg ICAgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwNyAgICBbUGFnZSAzMF0gDQoMSW50ZXJuZXQgRHJh ZnQgICAgICBCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcg DQogDQogDQogICAgDQogICAgICAgICBUYWJsZSAxOiBBZG1pbmlzdHJhdGl2ZSBSZWNvcmQgVHlw ZSBDb2RlcyANCiAgICANCiAgICAgICAgICstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAgVmFsdWUgIHwgICAgICAgICAg ICAgICAgICBNZWFuaW5nICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICArPT09PT09PT09 Kz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09KyANCiAgICAgICAg IHwgIDAwMDEgICB8ICBCdW5kbGUgc3RhdHVzIHJlcG9ydC4gICAgICAgICAgICAgICAgICAgICB8 IA0KICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsgDQogICAgICAgICB8ICAwMDEwICAgfCAgQ3VzdG9keSBzaWduYWwuICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICstLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAob3RoZXIpIHwg IFJlc2VydmVkIGZvciBmdXR1cmUgdXNlLiAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAr LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAN CiAgICANCiAgIEFkbWluaXN0cmF0aXZlIHJlY29yZCBmbGFncyBhcmUgZGVmaW5lZCBhcyBmb2xs b3dzOiANCiANCiAgICAgICAgIFRhYmxlIDI6IEFkbWluaXN0cmF0aXZlIFJlY29yZCBGbGFncyAN CiAgICANCiAgICAgICAgICstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAgVmFsdWUgIHwgICAgICAgICAgICAgICAgICBN ZWFuaW5nICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICArPT09PT09PT09Kz09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09KyANCiAgICAgICAgIHwgIDAwMDEg ICB8ICBSZWNvcmQgaXMgZm9yIGEgZnJhZ21lbnQ7IGZyYWdtZW50ICAgICAgICB8IA0KICAgICAg ICAgfCAgICAgICAgIHwgIG9mZnNldCBhbmQgbGVuZ3RoIGZpZWxkcyBhcmUgcHJlc2VudC4gICAg IHwgDQogICAgICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKyANCiAgICAgICAgIHwgKG90aGVyKSB8ICBSZXNlcnZlZCBmb3IgZnV0dXJl IHVzZS4gICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgDQogICBBbGwgdGltZSB2 YWx1ZXMgaW4gYWRtaW5pc3RyYXRpdmUgcmVjb3JkcyBhcmUgVVRDIHRpbWVzIGV4cHJlc3NlZCBp biANCiAgICJEVE4gdGltZSIgcmVwcmVzZW50YXRpb24uICBBIERUTiB0aW1lIGNvbnNpc3RzIG9m IGFuIFNETlYgaW5kaWNhdGluZyANCiAgIHRoZSBudW1iZXIgb2Ygc2Vjb25kcyBzaW5jZSB0aGUg c3RhcnQgb2YgdGhlIHllYXIgMjAwMCwgZm9sbG93ZWQgYnkgDQogICBhbiBTRE5WIGluZGljYXRp bmcgdGhlIG51bWJlciBvZiBuYW5vc2Vjb25kcyBzaW5jZSB0aGUgc3RhcnQgb2YgdGhlIA0KICAg aW5kaWNhdGVkIHNlY29uZC4gDQogICAgDQogICBUaGUgY29udGVudHMgb2YgdGhlIHZhcmlvdXMg dHlwZXMgb2YgYWRtaW5pc3RyYXRpdmUgcmVjb3JkcyBhcmUgDQogICBkZXNjcmliZWQgYmVsb3cu IA0KICAgIA0KNS4xLjEgQnVuZGxlIFN0YXR1cyBSZXBvcnRzIA0KICAgIA0KICAgVGhlIHRyYW5z bWlzc2lvbiBvZiAnYnVuZGxlIHN0YXR1cyByZXBvcnRzJyB1bmRlciBzcGVjaWZpZWQgDQogICBj b25kaXRpb25zIGlzIGFuIG9wdGlvbiB0aGF0IGNhbiBiZSBpbnZva2VkIHdoZW4gdHJhbnNtaXNz aW9uIG9mIGEgDQogICBidW5kbGUgaXMgcmVxdWVzdGVkLiAgVGhlc2UgcmVwb3J0cyBhcmUgaW50 ZW5kZWQgdG8gcHJvdmlkZSANCiAgIGluZm9ybWF0aW9uIGFib3V0IGhvdyBidW5kbGVzIGFyZSBw cm9ncmVzc2luZyB0aHJvdWdoIHRoZSBzeXN0ZW0sIA0KICAgaW5jbHVkaW5nIG5vdGljZXMgb2Yg cmVjZWlwdCwgY3VzdG9keSB0cmFuc2ZlciwgZm9yd2FyZGluZywgZmluYWwgDQogICBkZWxpdmVy eSwgYW5kIGRlbGV0aW9uLiAgVGhleSBhcmUgdHJhbnNtaXR0ZWQgdG8gdGhlIFJlcG9ydC10byAN CiAgIGVuZHBvaW50cyBvZiBidW5kbGVzLiANCiAgICANCg0KDQoNCg0KDQoNCiANCiANCksuIFNj b3R0IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwNyAgICBbUGFn ZSAzMV0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICBCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlv biAgICAgICAgIE1hcmNoIDIwMDcgDQogDQogDQogICBGb3JtYXQgb2YgQnVuZGxlIFN0YXR1cyBS ZXBvcnQgZm9yIGJ1bmRsZSAnWCc6IA0KICAgIA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgU3Rh dHVzIEZsYWdzICB8ICBSZWFzb24gY29kZSAgIHwgICAgICBGcmFnbWVudCBvZmZzZXQgKCopIChp ZiAgICAgIA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgIHByZXNlbnQpICAgICB8ICAgICAgRnJh Z21lbnQgbGVuZ3RoICgqKSAoaWYgcHJlc2VudCkgICAgICAgICAgICB8IA0KICAgKy0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0rIA0KICAgfCAgICAgICBUaW1lIG9mIHJlY2VpcHQgb2YgYnVuZGxlIFggKGEgRFROIHRpbWUs IGlmIHByZXNlbnQpICAgICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgVGltZSBvZiBj dXN0b2R5IGFjY2VwdGFuY2Ugb2YgYnVuZGxlIFggKGEgRFROIHRpbWUsIGlmIHByZXNlbnQpICB8 IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgICAgVGltZSBvZiBmb3J3YXJkaW5nIG9mIGJ1bmRs ZSBYIChhIERUTiB0aW1lLCBpZiBwcmVzZW50KSAgICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0K ICAgfCAgICAgIFRpbWUgb2YgZGVsaXZlcnkgb2YgYnVuZGxlIFggKGEgRFROIHRpbWUsIGlmIHBy ZXNlbnQpICAgICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgICAgIFRpbWUgb2YgZGVs ZXRpb24gb2YgYnVuZGxlIFggKGEgRFROIHRpbWUsIGlmIHByZXNlbnQpICAgICAgICB8IA0KICAg Ky0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0rIA0KICAgfCAgICAgICAgICBDb3B5IG9mIGJ1bmRsZSBYJ3MgQ3JlYXRpb24g VGltZXN0YW1wIHRpbWUgKCopICAgICAgICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAg ICAgQ29weSBvZiBidW5kbGUgWCdzIENyZWF0aW9uIFRpbWVzdGFtcCBzZXF1ZW5jZSBudW1iZXIg KCopICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgICAgIExlbmd0aCBvZiBYJ3Mgc291 cmNlIGVuZHBvaW50IElEICgqKSAgICAgICAgfCAgIFNvdXJjZSAgICAgICAgIA0KICAgKy0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAg ICAgICArIA0KICAgICAgICAgICAgICAgICAgICAgICAgZW5kcG9pbnQgSUQgb2YgYnVuZGxlIFgg KHZhcmlhYmxlKSAgICAgICAgICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgDQogICgqKSBO b3RlczogDQogICANCiAgVGhlIEZyYWdtZW50IE9mZnNldCBmaWVsZCwgaWYgcHJlc2VudCwgaXMg YW4gU0ROViBhbmQgaXMgdGhlcmVmb3JlIA0KICB2YXJpYWJsZS1sZW5ndGguICBBIHRocmVlLW9j dGV0IFNETlYgaXMgc2hvd24gaGVyZSBmb3IgY29udmVuaWVuY2UgaW4gDQogIHJlcHJlc2VudGF0 aW9uLiANCiAgIA0KICBUaGUgRnJhZ21lbnQgTGVuZ3RoIGZpZWxkLCBpZiBwcmVzZW50LCBpcyBh biBTRE5WIGFuZCBpcyB0aGVyZWZvcmUgDQogIHZhcmlhYmxlLWxlbmd0aC4gIEEgdGhyZWUtb2N0 ZXQgU0ROViBpcyBzaG93biBoZXJlIGZvciBjb252ZW5pZW5jZSBpbiANCiAgcmVwcmVzZW50YXRp b24uIA0KICAgDQogIFRoZSBDcmVhdGlvbiBUaW1lc3RhbXAgZmllbGRzIHJlcGxpY2F0ZSB0aGUg Q3JlYXRpb24gVGltZXN0YW1wIGZpZWxkcyANCiAgaW4gdGhlIHByaW1hcnkgYmxvY2sgb2YgdGhl IHN1YmplY3QgYnVuZGxlLiAgQXMgc3VjaCB0aGV5IGFyZSBTRE5WcyANCiAgKHNlZSAzLjYuMSBh Ym92ZSkgYW5kIGFyZSB0aGVyZWZvcmUgdmFyaWFibGUtbGVuZ3RoLiAgRm91ci1vY3RldCANCiAg U0ROVnMgYXJlIHNob3duIGhlcmUgZm9yIGNvbnZlbmllbmNlIGluIHJlcHJlc2VudGF0aW9uLiAN CiAgIA0KICBUaGUgc291cmNlIGVuZHBvaW50IElEIGxlbmd0aCBmaWVsZCBpcyBhbiBTRE5WIGFu ZCBpcyB0aGVyZWZvcmUgDQogIHZhcmlhYmxlLWxlbmd0aC4gIEEgdGhyZWUtb2N0ZXQgU0ROViBp cyBzaG93biBoZXJlIGZvciBjb252ZW5pZW5jZSBpbiANCiAgcmVwcmVzZW50YXRpb24uIA0KICAg IA0KDQoNCg0KDQoNCg0KIA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJl cyAtIFNlcHRlbWJlciAyMDA3ICAgIFtQYWdlIDMyXSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1 bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCiAg IFRoZSBmaWVsZHMgaW4gYSBidW5kbGUgc3RhdHVzIHJlcG9ydCBhcmU6IA0KICAgIA0KICAgU3Rh dHVzIEZsYWdzLiAgQSAxLWJ5dGUgZmllbGQgY29udGFpbmluZyB0aGUgZm9sbG93aW5nIGZsYWdz OiANCiAgICANCiAgICAgICAgIFRhYmxlIDM6IFN0YXR1cyBGbGFncyBmb3IgQnVuZGxlIFN0YXR1 cyBSZXBvcnRzIA0KICAgIA0KICAgICAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAgVmFsdWUgICB8ICAgICAg ICAgICAgICAgICAgTWVhbmluZyAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgKz09PT09 PT09PT0rPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0rIA0KICAg ICAgICAgfCAwMDAwMDAwMSB8ICBSZXBvcnRpbmcgbm9kZSByZWNlaXZlZCBidW5kbGUuICAgICAg ICAgICB8IA0KICAgICAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAwMDAwMDAxMCB8ICBSZXBvcnRpbmcgbm9k ZSBhY2NlcHRlZCBjdXN0b2R5IG9mIGJ1bmRsZS58IA0KICAgICAgICAgKy0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAw MDAwMDEwMCB8ICBSZXBvcnRpbmcgbm9kZSBmb3J3YXJkZWQgdGhlIGJ1bmRsZS4gICAgICB8IA0K ICAgICAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rIA0KICAgICAgICAgfCAwMDAwMTAwMCB8ICBSZXBvcnRpbmcgbm9kZSBkZWxpdmVy ZWQgdGhlIGJ1bmRsZS4gICAgICB8IA0KICAgICAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAwMDAxMDAwMCB8 ICBSZXBvcnRpbmcgbm9kZSBkZWxldGVkIHRoZSBidW5kbGUuICAgICAgICB8IA0KICAgICAgICAg Ky0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r IA0KICAgICAgICAgfCAwMDEwMDAwMCB8ICBVbnVzZWQuICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IA0KICAgICAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAwMTAwMDAwMCB8ICBVbnVzZWQu ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgKy0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAg ICAgfCAxMDAwMDAwMCB8ICBVbnVzZWQuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rIA0KICAgIA0KICAgUmVhc29uIGNvZGUuICBBIDEtYnl0ZSBmaWVsZCBl eHBsYWluaW5nIHRoZSB2YWx1ZSBvZiB0aGUgZmxhZ3MgaW4gdGhlIA0KICAgICAgICAgIHN0YXR1 cyBmbGFncyBieXRlLiAgVGhlIGxpc3Qgb2Ygc3RhdHVzIHJlcG9ydCByZWFzb24gY29kZXMgDQog ICAgICAgICAgcHJvdmlkZWQgaGVyZSBpcyBuZWl0aGVyIGV4aGF1c3RpdmUgbm9yIGV4Y2x1c2l2 ZTsgDQogICAgICAgICAgc3VwcGxlbWVudGFyeSBEVE4gcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMg KGluY2x1ZGluZywgYnV0IG5vdCANCiAgICAgICAgICByZXN0cmljdGVkIHRvLCB0aGUgQnVuZGxl IFNlY3VyaXR5IFByb3RvY29sIFs1XSkgbWF5IGRlZmluZSANCiAgICAgICAgICBhZGRpdGlvbmFs IHJlYXNvbiBjb2Rlcy4gIFN0YXR1cyByZXBvcnQgcmVhc29uIGNvZGVzIGFyZSANCiAgICAgICAg ICBkZWZpbmVkIGFzIGZvbGxvd3M6IA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KIA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJlcyAtIFNlcHRlbWJl ciAyMDA3ICAgIFtQYWdlIDMzXSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1bmRsZSBQcm90b2Nv bCBTcGVjaWZpY2F0aW9uICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCiAgICANCiAgICAgICAg IFRhYmxlIDQ6IFN0YXR1cyBSZXBvcnQgUmVhc29uIENvZGVzIA0KICAgIA0KICAgICAgICAgKy0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQog ICAgICAgICB8ICBWYWx1ZSAgfCAgICAgICAgICAgICAgICAgIE1lYW5pbmcgICAgICAgICAgICAg ICAgICAgfCANCiAgICAgICAgICs9PT09PT09PT0rPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0rIA0KICAgICAgICAgfCAgMHgwMCAgIHwgIE5vIGFkZGl0aW9uYWwg aW5mb3JtYXRpb24uICAgICAgICAgICAgICAgIHwgDQogICAgICAgICArLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAgIHwgIDB4 MDEgICB8ICBMaWZldGltZSBleHBpcmVkLiAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAg ICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsgDQogICAgICAgICB8ICAweDAyICAgfCAgRm9yd2FyZGVkIG92ZXIgdW5pZGlyZWN0aW9u YWwgbGluay4gICAgICAgfCANCiAgICAgICAgICstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAgMHgwMyAgIHwgIFRyYW5z bWlzc2lvbiBjYW5jZWxlZC4gICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICArLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAg ICAgIHwgIDB4MDQgICB8ICBEZXBsZXRlZCBzdG9yYWdlLiAgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsgDQogICAgICAgICB8ICAweDA1ICAgfCAgRGVzdGluYXRpb24gZW5kcG9p bnQgSUQgdW5pbnRlbGxpZ2libGUuICAgfCANCiAgICAgICAgICstLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAgMHgwNiAg IHwgIE5vIGtub3duIHJvdXRlIHRvIGRlc3RpbmF0aW9uIGZyb20gaGVyZS4gIHwgDQogICAgICAg ICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t KyANCiAgICAgICAgIHwgIDB4MDcgICB8ICBObyB0aW1lbHkgY29udGFjdCB3aXRoIG5leHQgbm9k ZSBvbiByb3V0ZS58IA0KICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICB8ICAweDA4ICAgfCAgQmxvY2sgdW5p bnRlbGxpZ2libGUuICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICstLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAg fCAob3RoZXIpIHwgIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlLiAgICAgICAgICAgICAgICAgIHwg DQogICAgICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKyANCiAgICANCiAgIEZyYWdtZW50IG9mZnNldC4gIElmIHRoZSBidW5kbGUgZnJh Z21lbnQgYml0IGlzIHNldCBpbiB0aGUgc3RhdHVzIA0KICAgICAgICAgIGZsYWdzLCB0aGVuIHRo ZSBvZmZzZXQgKHdpdGhpbiB0aGUgb3JpZ2luYWwgYXBwbGljYXRpb24gZGF0YSANCiAgICAgICAg ICB1bml0KSBvZiB0aGUgcGF5bG9hZCBvZiB0aGUgYnVuZGxlIHRoYXQgY2F1c2VkIHRoZSBzdGF0 dXMgDQogICAgICAgICAgcmVwb3J0IHRvIGJlIGdlbmVyYXRlZCBpcyBpbmNsdWRlZCBoZXJlLiAN CiAgICANCiAgIEZyYWdtZW50IGxlbmd0aC4gIElmIHRoZSBidW5kbGUgZnJhZ21lbnQgYml0IGlz IHNldCBpbiB0aGUgc3RhdHVzIA0KICAgICAgICAgIGZsYWdzLCB0aGVuIHRoZSBsZW5ndGggb2Yg dGhlIHBheWxvYWQgb2YgdGhlIHN1YmplY3QgYnVuZGxlIGlzIA0KICAgICAgICAgIGluY2x1ZGVk IGhlcmUuIA0KICAgIA0KICAgVGltZSBvZiBSZWNlaXB0IChpZiBwcmVzZW50KS4gIElmIHRoZSBi dW5kbGUtcmVjZWl2ZWQgYml0IGlzIHNldCBpbiANCiAgICAgICAgICB0aGUgc3RhdHVzIGZsYWdz LCB0aGVuIGEgRFROIHRpbWUgaW5kaWNhdGluZyB0aGUgdGltZSBhdCB3aGljaCANCiAgICAgICAg ICB0aGUgYnVuZGxlIHdhcyByZWNlaXZlZCBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgaW5jbHVk ZWQgDQogICAgICAgICAgaGVyZS4gDQogICAgDQogICBUaW1lIG9mIEN1c3RvZHkgQWNjZXB0YW5j ZSAoaWYgcHJlc2VudCkuICBJZiB0aGUgY3VzdG9keS1hY2NlcHRlZCBiaXQgDQogICAgICAgICAg aXMgc2V0IGluIHRoZSBzdGF0dXMgZmxhZ3MsIHRoZW4gYSBEVE4gdGltZSBpbmRpY2F0aW5nIHRo ZSANCiAgICAgICAgICB0aW1lIGF0IHdoaWNoIGN1c3RvZHkgd2FzIGFjY2VwdGVkIGF0IHRoZSBy ZXBvcnRpbmcgbm9kZSBpcyANCiAgICAgICAgICBpbmNsdWRlZCBoZXJlLiANCiAgICANCiAgIFRp bWUgb2YgRm9yd2FyZCAoaWYgcHJlc2VudCkuICBJZiB0aGUgYnVuZGxlLWZvcndhcmRlZCBiaXQg aXMgc2V0IGluIA0KICAgICAgICAgIHRoZSBzdGF0dXMgZmxhZ3MsIHRoZW4gYSBEVE4gdGltZSBp bmRpY2F0aW5nIHRoZSB0aW1lIGF0IHdoaWNoIA0KICAgICAgICAgIHRoZSBidW5kbGUgd2FzIGZp cnN0IGZvcndhcmRlZCBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgDQogICAgICAgICAgaW5jbHVk ZWQgaGVyZS4gDQogDQogDQogDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAgICBFeHBpcmVz IC0gU2VwdGVtYmVyIDIwMDcgICAgW1BhZ2UgMzRdIA0KDEludGVybmV0IERyYWZ0ICAgICAgQnVu ZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0KIA0KIA0KICAg VGltZSBvZiBEZWxpdmVyeSAoaWYgcHJlc2VudCkuICBJZiB0aGUgYnVuZGxlLWRlbGl2ZXJlZCBi aXQgaXMgc2V0IGluIA0KICAgICAgICAgIHRoZSBzdGF0dXMgZmxhZ3MsIHRoZW4gYSBEVE4gdGlt ZSBpbmRpY2F0aW5nIHRoZSB0aW1lIGF0IHdoaWNoIA0KICAgICAgICAgIHRoZSBidW5kbGUgd2Fz IGRlbGl2ZXJlZCBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgaW5jbHVkZWQgDQogICAgICAgICAg aGVyZS4gDQogICAgDQogICBUaW1lIG9mIERlbGV0aW9uIChpZiBwcmVzZW50KS4gIElmIHRoZSBi dW5kbGUtZGVsZXRlZCBiaXQgaXMgc2V0IGluIA0KICAgICAgICAgIHRoZSBzdGF0dXMgZmxhZ3Ms IHRoZW4gYSBEVE4gdGltZSBpbmRpY2F0aW5nIHRoZSB0aW1lIGF0IHdoaWNoIA0KICAgICAgICAg IHRoZSBidW5kbGUgd2FzIGRlbGV0ZWQgYXQgdGhlIHJlcG9ydGluZyBub2RlIGlzIGluY2x1ZGVk IGhlcmUuIA0KICAgIA0KICAgQ3JlYXRpb24gVGltZXN0YW1wIG9mIFN1YmplY3QgQnVuZGxlLiAg QSBjb3B5IG9mIHRoZSBjcmVhdGlvbiANCiAgICAgICAgICB0aW1lc3RhbXAgb2YgdGhlIGJ1bmRs ZSB0aGF0IGNhdXNlZCB0aGUgc3RhdHVzIHJlcG9ydCB0byBiZSANCiAgICAgICAgICBnZW5lcmF0 ZWQuIA0KICAgIA0KICAgTGVuZ3RoIG9mIFNvdXJjZSBFbmRwb2ludCBJRC4gIFRoZSBsZW5ndGgg aW4gYnl0ZXMgb2YgdGhlIHNvdXJjZSANCiAgICAgICAgICBlbmRwb2ludCBJRCBvZiB0aGUgYnVu ZGxlIHRoYXQgY2F1c2VkIHRoZSBzdGF0dXMgcmVwb3J0IHRvIGJlIA0KICAgICAgICAgIGdlbmVy YXRlZC4gDQogICAgDQogIFNvdXJjZSBFbmRwb2ludCBJRCB0ZXh0LiAgVGhlIHRleHQgb2YgdGhl IHNvdXJjZSBlbmRwb2ludCBJRCBvZiB0aGUgDQogICAgICAgICAgYnVuZGxlIHRoYXQgY2F1c2Vk IHRoZSBzdGF0dXMgcmVwb3J0IHRvIGJlIGdlbmVyYXRlZC4gDQogICANCjUuMS4yIEN1c3RvZHkg U2lnbmFscyANCiAgICANCiAgIEN1c3RvZHkgc2lnbmFscyBhcmUgYWRtaW5pc3RyYXRpdmUgcmVj b3JkcyB0aGF0IGVmZmVjdCBjdXN0b2R5IA0KICAgdHJhbnNmZXIgb3BlcmF0aW9ucy4gIFRoZXkg YXJlIHRyYW5zbWl0dGVkIHRvIHRoZSBlbmRwb2ludHMgdGhhdCBhcmUgDQogICB0aGUgY3VycmVu dCBjdXN0b2RpYW5zIG9mIGJ1bmRsZXMuIA0KICAgIA0KICAgQ3VzdG9keSBzaWduYWxzIGhhdmUg dGhlIGZvbGxvd2luZyBmb3JtYXQuIA0KICAgIA0KICAgQ3VzdG9keSBTaWduYWwgcmVnYXJkaW5n IGJ1bmRsZSAnWCc6IA0KICAgIA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgICAgU3RhdHVzICAg ICB8ICAgICAgRnJhZ21lbnQgb2Zmc2V0ICgqKSAoaWYgcHJlc2VudCkgICAgICAgICAgICB8IA0K ICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgICAgICAgICAgICAgICAgICBGcmFnbWVudCBsZW5ndGgg KCopIChpZiBwcmVzZW50KSAgICAgICAgICAgICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAg fCAgICAgICAgICAgICAgICAgICBUaW1lIG9mIHNpZ25hbCAoYSBEVE4gdGltZSkgICAgICAgICAg ICAgICAgICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgICAgICAgICBDb3B5IG9mIGJ1 bmRsZSBYJ3MgQ3JlYXRpb24gVGltZXN0YW1wIHRpbWUgKCopICAgICAgICAgICB8IA0KICAgKy0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0rIA0KICAgfCAgICAgQ29weSBvZiBidW5kbGUgWCdzIENyZWF0aW9uIFRpbWVzdGFt cCBzZXF1ZW5jZSBudW1iZXIgKCopICAgICB8IA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rIA0KICAgfCAgICAg IExlbmd0aCBvZiBYJ3Mgc291cmNlIGVuZHBvaW50IElEICgqKSAgICAgICAgfCAgIFNvdXJjZSAg ICAgICAgIA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKyAgICAgICAgICAgICAgICArIA0KICAgICAgICAgICAgICAgICAgICAgICAgZW5kcG9p bnQgSUQgb2YgYnVuZGxlIFggKHZhcmlhYmxlKSAgICAgICAgICAgICB8IA0KICAgKy0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0rIA0KICAgDQogICgqKSBOb3RlczogDQogICANCiAgVGhlIEZyYWdtZW50IE9mZnNldCBmaWVs ZCwgaWYgcHJlc2VudCwgaXMgYW4gU0ROViBhbmQgaXMgdGhlcmVmb3JlIA0KICB2YXJpYWJsZS1s ZW5ndGguICBBIHRocmVlLW9jdGV0IFNETlYgaXMgc2hvd24gaGVyZSBmb3IgY29udmVuaWVuY2Ug aW4gDQogIHJlcHJlc2VudGF0aW9uLiANCiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAg ICAgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwNyAgICBbUGFnZSAzNV0gDQoMSW50ZXJuZXQgRHJh ZnQgICAgICBCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcg DQogDQogDQogICANCiAgVGhlIEZyYWdtZW50IExlbmd0aCBmaWVsZCwgaWYgcHJlc2VudCwgaXMg YW4gU0ROViBhbmQgaXMgdGhlcmVmb3JlIA0KICB2YXJpYWJsZS1sZW5ndGguICBBIGZvdXItb2N0 ZXQgU0ROViBpcyBzaG93biBoZXJlIGZvciBjb252ZW5pZW5jZSBpbiANCiAgcmVwcmVzZW50YXRp b24uIA0KICAgDQogIFRoZSBDcmVhdGlvbiBUaW1lc3RhbXAgZmllbGRzIHJlcGxpY2F0ZSB0aGUg Q3JlYXRpb24gVGltZXN0YW1wIGZpZWxkcyANCiAgaW4gdGhlIHByaW1hcnkgYmxvY2sgb2YgdGhl IHN1YmplY3QgYnVuZGxlLiAgQXMgc3VjaCB0aGV5IGFyZSBTRE5WcyANCiAgKHNlZSAzLjYuMSBh Ym92ZSkgYW5kIGFyZSB0aGVyZWZvcmUgdmFyaWFibGUtbGVuZ3RoLiAgRm91ci1vY3RldCANCiAg U0ROVnMgYXJlIHNob3duIGhlcmUgZm9yIGNvbnZlbmllbmNlIGluIHJlcHJlc2VudGF0aW9uLiAN CiAgIA0KICBUaGUgc291cmNlIGVuZHBvaW50IElEIGxlbmd0aCBmaWVsZCBpcyBhbiBTRE5WIGFu ZCBpcyB0aGVyZWZvcmUgDQogIHZhcmlhYmxlLWxlbmd0aC4gIEEgdGhyZWUtb2N0ZXQgU0ROViBp cyBzaG93biBoZXJlIGZvciBjb252ZW5pZW5jZSBpbiANCiAgcmVwcmVzZW50YXRpb24uIA0KICAg IA0KICAgVGhlIGZpZWxkcyBpbiBhIGN1c3RvZHkgc2lnbmFsIGFyZTogDQogICAgDQogICBTdGF0 dXMuICBBIDEtYnl0ZSBmaWVsZCBjb250YWluaW5nIGEgMS1iaXQgImN1c3RvZHkgdHJhbnNmZXIg DQogICBzdWNjZWVkZWQiIGZsYWcgZm9sbG93ZWQgYnkgYSA3LWJpdCByZWFzb24gY29kZSBleHBs YWluaW5nIHRoZSB2YWx1ZSANCiAgIG9mIHRoYXQgZmxhZy4gIEN1c3RvZHkgc2lnbmFsIHJlYXNv biBjb2RlcyBhcmUgZGVmaW5lZCBhcyBmb2xsb3dzOiANCiAgICANCiAgICAgICAgIFRhYmxlIDU6 IEN1c3RvZHkgU2lnbmFsIFJlYXNvbiBDb2RlcyANCiAgICANCiAgICAgICAgICstLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAg fCAgVmFsdWUgIHwgICAgICAgICAgICAgICAgICBNZWFuaW5nICAgICAgICAgICAgICAgICAgIHwg DQogICAgICAgICArPT09PT09PT09Kz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09KyANCiAgICAgICAgIHwgIDB4MDAgICB8ICBObyBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uLiAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICB8ICAweDAxICAgfCAg UmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICst LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0K ICAgICAgICAgfCAgMHgwMiAgIHwgIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlLiAgICAgICAgICAg ICAgICAgIHwgDQogICAgICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAgIHwgIDB4MDMgICB8ICBSZWR1bmRhbnQgcmVj ZXB0aW9uIChyZWNlcHRpb24gYnkgYSBub2RlICB8IA0KICAgICAgICAgfCAgICAgICAgIHwgIHRo YXQgaXMgYSBjdXN0b2RpYWwgbm9kZSBmb3IgdGhpcyBidW5kbGUpLnwgDQogICAgICAgICArLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAg ICAgICAgIHwgIDB4MDQgICB8ICBEZXBsZXRlZCBzdG9yYWdlLiAgICAgICAgICAgICAgICAgICAg ICAgICB8IA0KICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICB8ICAweDA1ICAgfCAgRGVzdGluYXRpb24gZW5k cG9pbnQgSUQgdW5pbnRlbGxpZ2libGUuICAgfCANCiAgICAgICAgICstLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgfCAgMHgw NiAgIHwgIE5vIGtub3duIHJvdXRlIHRvIGRlc3RpbmF0aW9uIGZyb20gaGVyZS4gIHwgDQogICAg ICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKyANCiAgICAgICAgIHwgIDB4MDcgICB8ICBObyB0aW1lbHkgY29udGFjdCB3aXRoIG5leHQg bm9kZSBvbiByb3V0ZS58IA0KICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICB8ICAweDA4ICAgfCAgQmxvY2sg dW5pbnRlbGxpZ2libGUuICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICstLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAg ICAgfCAob3RoZXIpIHwgIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlLiAgICAgICAgICAgICAgICAg IHwgDQogICAgICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKyANCiAgICANCiAgIEZyYWdtZW50IG9mZnNldC4gIElmIHRoZSBidW5kbGUg ZnJhZ21lbnQgYml0IGlzIHNldCBpbiB0aGUgc3RhdHVzIA0KICAgICAgICAgIGZsYWdzLCB0aGVu IHRoZSBvZmZzZXQgKHdpdGhpbiB0aGUgb3JpZ2luYWwgYXBwbGljYXRpb24gZGF0YSANCiAgICAg ICAgICB1bml0KSBvZiB0aGUgcGF5bG9hZCBvZiB0aGUgYnVuZGxlIHRoYXQgY2F1c2VkIHRoZSBz dGF0dXMgDQogICAgICAgICAgcmVwb3J0IHRvIGJlIGdlbmVyYXRlZCBpcyBpbmNsdWRlZCBoZXJl LiANCiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4cGlyZXMgLSBTZXB0ZW1i ZXIgMjAwNyAgICBbUGFnZSAzNl0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICBCdW5kbGUgUHJvdG9j b2wgU3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcgDQogDQogDQogICAgDQogICBGcmFn bWVudCBsZW5ndGguICBJZiB0aGUgYnVuZGxlIGZyYWdtZW50IGJpdCBpcyBzZXQgaW4gdGhlIHN0 YXR1cyANCiAgICAgICAgICBmbGFncywgdGhlbiB0aGUgbGVuZ3RoIG9mIHRoZSBwYXlsb2FkIG9m IHRoZSBzdWJqZWN0IGJ1bmRsZSBpcyANCiAgICAgICAgICBpbmNsdWRlZCBoZXJlLiANCiAgICAN CiAgIFRpbWUgb2YgU2lnbmFsLiAgQSBEVE4gdGltZSBpbmRpY2F0aW5nIHRoZSB0aW1lIGF0IHdo aWNoIHRoZSBzaWduYWwgDQogICAgICAgICAgd2FzIGdlbmVyYXRlZC4gDQogICAgDQogICBDcmVh dGlvbiBUaW1lc3RhbXAgb2YgU3ViamVjdCBCdW5kbGUuICBBIGNvcHkgb2YgdGhlIGNyZWF0aW9u IA0KICAgICAgICAgIHRpbWVzdGFtcCBvZiB0aGUgYnVuZGxlIHRvIHdoaWNoIHRoZSBzaWduYWwg YXBwbGllcy4gDQogICAgDQogICBMZW5ndGggb2YgU291cmNlIEVuZHBvaW50IElELiAgVGhlIGxl bmd0aCBpbiBieXRlcyBvZiB0aGUgc291cmNlIA0KICAgICAgICAgIGVuZHBvaW50IElEIG9mIHRo ZSBidW5kbGUgdG8gd2hpY2ggdGhlIHNpZ25hbCBhcHBsaWVkLiANCiAgICANCiAgU291cmNlIEVu ZHBvaW50IElEIHRleHQuICBUaGUgdGV4dCBvZiB0aGUgc291cmNlIGVuZHBvaW50IElEIG9mIHRo ZSANCiAgICAgICAgICBidW5kbGUgdG8gd2hpY2ggdGhlIHNpZ25hbCBhcHBsaWVzLiANCiAgICAN CjUuMiBHZW5lcmF0aW9uIG9mIGFkbWluaXN0cmF0aXZlIHJlY29yZHMgDQogICANCiAgV2hlbmV2 ZXIgdGhlIGFwcGxpY2F0aW9uIGFnZW50J3MgYWRtaW5pc3RyYXRpdmUgZWxlbWVudCBpcyBkaXJl Y3RlZCANCiAgYnkgdGhlIGJ1bmRsZSBwcm90b2NvbCBhZ2VudCB0byBnZW5lcmF0ZSBhbiBhZG1p bmlzdHJhdGl2ZSByZWNvcmQgDQogIHdpdGggcmVmZXJlbmNlIHRvIHNvbWUgYnVuZGxlLCB0aGUg Zm9sbG93aW5nIHByb2NlZHVyZSBtdXN0IGJlIA0KICBmb2xsb3dlZDogDQogICANCiAgU3RlcCAx OiBUaGUgYWRtaW5pc3RyYXRpdmUgcmVjb3JkIG11c3QgYmUgY29uc3RydWN0ZWQuICBJZiB0aGUg DQogIHJlZmVyZW5jZWQgYnVuZGxlIGlzIGEgZnJhZ21lbnQsIHRoZSBhZG1pbmlzdHJhdGl2ZSBy ZWNvcmQgbXVzdCBoYXZlIA0KICB0aGUgRnJhZ21lbnQgZmxhZyBzZXQgYW5kIG11c3QgY29udGFp biB0aGUgZnJhZ21lbnQgb2Zmc2V0IGFuZCANCiAgZnJhZ21lbnQgbGVuZ3RoIGZpZWxkczsgdGhl IHZhbHVlIG9mIHRoZSBmcmFnbWVudCBvZmZzZXQgZmllbGQgbXVzdCANCiAgYmUgdGhlIHZhbHVl IG9mIHRoZSByZWZlcmVuY2VkIGJ1bmRsZSdzIGZyYWdtZW50IG9mZnNldCwgYW5kIHRoZSANCiAg dmFsdWUgb2YgdGhlIGZyYWdtZW50IGxlbmd0aCBmaWVsZCBtdXN0IGJlIHRoZSBsZW5ndGggb2Yg dGhlIA0KICByZWZlcmVuY2VkIGJ1bmRsZSdzIHBheWxvYWQuIA0KICAgDQogIFN0ZXAgMjogIEEg cmVxdWVzdCBmb3IgdHJhbnNtaXNzaW9uIG9mIGEgYnVuZGxlIHdob3NlIHBheWxvYWQgaXMgdGhp cyANCiAgYWRtaW5pc3RyYXRpdmUgcmVjb3JkIG11c3QgYmUgcHJlc2VudGVkIHRvIHRoZSBidW5k bGUgcHJvdG9jb2wgYWdlbnQuIA0KICAgDQo1LjMgUmVjZXB0aW9uIG9mIGN1c3RvZHkgc2lnbmFs cyANCiAgIA0KICAgRm9yIGVhY2ggcmVjZWl2ZWQgY3VzdG9keSBzaWduYWwgdGhhdCBoYXMgdGhl IEN1c3RvZHkgVHJhbnNmZXIgDQogICBTdWNjZWVkZWQgIGZsYWcgIHNldCAgdG8gIDEsICB0aGUg IGFkbWluaXN0cmF0aXZlICBlbGVtZW50ICBvZiAgdGhlIA0KICAgYXBwbGljYXRpb24gYWdlbnQg bXVzdCBkaXJlY3QgdGhlIGJ1bmRsZSBwcm90b2NvbCBhZ2VudCB0byBmb2xsb3cgdGhlIA0KICAg Y3VzdG9keSB0cmFuc2ZlciBzdWNjZXNzIHByb2NlZHVyZSBpbiA0LjExLiANCiAgICANCiAgIEZv ciBlYWNoIHJlY2VpdmVkIGN1c3RvZHkgc2lnbmFsIHRoYXQgaGFzIHRoZSBDdXN0b2R5IFRyYW5z ZmVyIA0KICAgU3VjY2VlZGVkICBmbGFnICBzZXQgIHRvICAwLCAgdGhlICBhZG1pbmlzdHJhdGl2 ZSAgZWxlbWVudCAgb2YgIHRoZSANCiAgIGFwcGxpY2F0aW9uIGFnZW50IG11c3QgZGlyZWN0IHRo ZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQgdG8gZm9sbG93IHRoZSANCiAgIGN1c3RvZHkgdHJhbnNm ZXIgZmFpbHVyZSBwcm9jZWR1cmUgaW4gNC4xMi4gDQogICANCg0KDQoNCg0KIA0KIA0KSy4gU2Nv dHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhwaXJlcyAtIFNlcHRlbWJlciAyMDA3ICAgIFtQYWdl IDM3XSANCgxJbnRlcm5ldCBEcmFmdCAgICAgIEJ1bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9u ICAgICAgICAgTWFyY2ggMjAwNyANCiANCiANCjYuICAgU2VydmljZXMgUmVxdWlyZWQgb2YgdGhl IENvbnZlcmdlbmNlIExheWVyIA0KICAgIA0KNi4xIFRoZSBDb252ZXJnZW5jZSBMYXllciANCiAg ICANCiAgIFRoZSBzdWNjZXNzZnVsIG9wZXJhdGlvbiBvZiB0aGUgZW5kLXRvLWVuZCBidW5kbGUg cHJvdG9jb2wgZGVwZW5kcyBvbiANCiAgIHRoZSAgb3BlcmF0aW9uICBvZiAgdW5kZXJseWluZyAg cHJvdG9jb2xzICBhdCAgd2hhdCAgaXMgIHRlcm1lZCAgdGhlIA0KICAgImNvbnZlcmdlbmNlIGxh eWVyIjsgdGhlc2UgcHJvdG9jb2xzIGFjY29tcGxpc2ggY29tbXVuaWNhdGlvbiBiZXR3ZWVuIA0K ICAgbm9kZXMuICBBIHdpZGUgdmFyaWV0eSBvZiBwcm90b2NvbHMgbWF5IHNlcnZlIHRoaXMgcHVy cG9zZSwgc28gbG9uZyANCiAgIGFzIGVhY2ggY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2wgYWRh cHRlciBwcm92aWRlcyBhIGRlZmluZWQgbWluaW1hbCANCiAgIHNldCBvZiBzZXJ2aWNlcyB0byB0 aGUgYnVuZGxlIHByb3RvY29sIGFnZW50LiAgVGhpcyBjb252ZXJnZW5jZSBsYXllciANCiAgIHNl cnZpY2Ugc3BlY2lmaWNhdGlvbiBlbnVtZXJhdGVzIHRob3NlIHNlcnZpY2VzLiANCiAgICANCjYu MiBTdW1tYXJ5IG9mIENvbnZlcmdlbmNlIExheWVyIFNlcnZpY2VzIA0KICAgIA0KICAgRWFjaCBj b252ZXJnZW5jZSBsYXllciBwcm90b2NvbCBhZGFwdGVyIGlzIGV4cGVjdGVkIHRvIHByb3ZpZGUg dGhlIA0KICAgZm9sbG93aW5nIHNlcnZpY2VzIHRvIHRoZSBidW5kbGUgcHJvdG9jb2wgYWdlbnQ6 IA0KICAgIA0KICAgICAgYSkgc2VuZGluZyBhIGJ1bmRsZSB0byBhbGwgYnVuZGxlIG5vZGVzIGlu IHRoZSBtaW5pbXVtIHJlY2VwdGlvbiANCiAgICAgICAgZ3JvdXAgb2YgdGhlIGVuZHBvaW50IGlk ZW50aWZpZWQgYnkgYSBzcGVjaWZpZWQgZW5kcG9pbnQgSUQgDQogICAgICAgIHRoYXQgYXJlIHJl YWNoYWJsZSB2aWEgdGhlIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sOyANCiAgICANCiAgICAg IGIpIGRlbGl2ZXJpbmcgdG8gdGhlIGJ1bmRsZSBwcm90b2NvbCBhZ2VudCBhIGJ1bmRsZSB0aGF0 IHdhcyBzZW50IA0KICAgICAgICBieSBhIHJlbW90ZSBidW5kbGUgbm9kZSB2aWEgdGhlIGNvbnZl cmdlbmNlIGxheWVyIHByb3RvY29sLiANCiAgICANCiAgVGhlIGNvbnZlcmdlbmNlIGxheWVyIHNl cnZpY2UgaW50ZXJmYWNlIHNwZWNpZmllZCBoZXJlIGlzIG5laXRoZXIgDQogIGV4aGF1c3RpdmUg bm9yIGV4Y2x1c2l2ZS4gIFRoYXQgaXMsIHN1cHBsZW1lbnRhcnkgRFROIHByb3RvY29sIA0KICBz cGVjaWZpY2F0aW9ucyAoaW5jbHVkaW5nLCBidXQgbm90IHJlc3RyaWN0ZWQgdG8sIHRoZSBCdW5k bGUgU2VjdXJpdHkgDQogIFByb3RvY29sIFs1XSkgbWF5IGV4cGVjdCBjb252ZXJnZW5jZSBsYXll ciBhZGFwdGVycyB3aGljaCBzZXJ2ZSBCUCANCiAgaW1wbGVtZW50YXRpb25zIGNvbmZvcm1pbmcg dG8gdGhvc2UgcHJvdG9jb2xzIHRvIHByb3ZpZGUgYWRkaXRpb25hbCANCiAgc2VydmljZXMuIA0K ICAgIA0KNy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogICAgDQogICBUaGUgYnVuZGxlIHBy b3RvY29sIGhhcyB0YWtlbiBzZWN1cml0eSBpbnRvIGNvbmNlcm4gZnJvbSB0aGUgb3V0c2V0IA0K ICAgb2YgaXRzIGRlc2lnbi4gIEl0IHdhcyBhbHdheXMgYXNzdW1lZCB0aGF0IHNlY3VyaXR5IHNl cnZpY2VzIHdvdWxkIGJlIA0KICAgbmVlZGVkIGluIHRoZSB1c2Ugb2YgdGhlIGJ1bmRsZSBwcm90 b2NvbC4gIEFzIGEgcmVzdWx0LCB0aGUgYnVuZGxlIA0KICAgcHJvdG9jb2wgc2VjdXJpdHkgYXJj aGl0ZWN0dXJlIGFuZCB0aGUgYXZhaWxhYmxlIHNlY3VyaXR5IHNlcnZpY2VzIA0KICAgYXJlIHNw ZWNpZmllZCBpbiBhbiBhY2NvbXBhbnlpbmcgZG9jdW1lbnQsIHRoZSBCdW5kbGUgU2VjdXJpdHkg DQogICBQcm90b2NvbCBzcGVjaWZpY2F0aW9uIFs1XTsgYW4gaW5mb3JtYXRpdmUgb3ZlcnZpZXcg b2YgdGhpcyANCiAgIGFyY2hpdGVjdHVyZSBpcyBwcm92aWRlZCBpbiBbNl0uICANCiAgICANCiAg IFRoZSBidW5kbGUgcHJvdG9jb2wgaGFzIGJlZW4gZGVzaWduZWQgd2l0aCB0aGUgbm90aW9uIHRo YXQgaXQgd2lsbCBiZSANCiAgIHJ1biBvdmVyIG5ldHdvcmtzIHdpdGggc2NhcmNlIHJlc291cmNl cy4gIEZvciBleGFtcGxlLCB0aGUgbmV0d29ya3MgDQogICBtaWdodCBoYXZlIGxpbWl0ZWQgYmFu ZHdpZHRoLCBsaW1pdGVkIGNvbm5lY3Rpdml0eSwgY29uc3RyYWluZWQgDQogICBzdG9yYWdlIGlu IHJlbGF5IG5vZGVzLCBldGMuICBUaGVyZWZvcmUsIHRoZSBidW5kbGUgcHJvdG9jb2wgbXVzdCAN CiAgIGVuc3VyZSB0aGF0IG9ubHkgdGhvc2UgZW50aXRpZXMgYXV0aG9yaXplZCB0byBzZW5kIGJ1 bmRsZXMgb3ZlciBzdWNoIA0KICAgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzIGFyZSBhY3R1YWxs eSBhbGxvd2VkIHRvIGRvIHNvLiAgQWxsIA0KICAgdW5hdXRob3JpemVkIGVudGl0aWVzIHNob3Vs ZCBiZSBwcmV2ZW50ZWQgZnJvbSBjb25zdW1pbmcgdmFsdWFibGUgDQogICByZXNvdXJjZXMuIA0K ICAgIA0KICAgTGlrZXdpc2UsIGJlY2F1c2Ugb2YgdGhlIHBvdGVudGlhbGx5IGxvbmcgbGF0ZW5j aWVzIGFuZCBkZWxheXMgDQogDQogDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAgICBFeHBp cmVzIC0gU2VwdGVtYmVyIDIwMDcgICAgW1BhZ2UgMzhdIA0KDEludGVybmV0IERyYWZ0ICAgICAg QnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0KIA0KIA0K ICAgaW52b2x2ZWQgaW4gdGhlIG5ldHdvcmtzIHRoYXQgbWFrZSB1c2Ugb2YgdGhlIGJ1bmRsZSBw cm90b2NvbCwgZGF0YSANCiAgIHNvdXJjZXMgc2hvdWxkIGJlIGNvbmNlcm5lZCB3aXRoIHRoZSBp bnRlZ3JpdHkgb2YgdGhlIGRhdGEgcmVjZWl2ZWQgDQogICBhdCB0aGUgaW50ZW5kZWQgZGVzdGlu YXRpb24ocykgYW5kIG1heSBhbHNvIGJlIGNvbmNlcm5lZCB3aXRoIA0KICAgZW5zdXJpbmcgY29u ZmlkZW50aWFsaXR5IG9mIHRoZSBkYXRhIGFzIGl0IHRyYXZlcnNlcyB0aGUgbmV0d29yay4gIA0K ICAgV2l0aG91dCBpbnRlZ3JpdHksIHRoZSBidW5kbGUgcGF5bG9hZCBkYXRhIG1pZ2h0IGJlIGNv cnJ1cHRlZCB3aGlsZSANCiAgIGluIHRyYW5zaXQgd2l0aG91dCB0aGUgZGVzdGluYXRpb24gYWJs ZSB0byBkZXRlY3QgaXQuICBTaW1pbGFybHksIHRoZSANCiAgIGRhdGEgc291cmNlIGNhbiBiZSBj b25jZXJuZWQgd2l0aCBlbnN1cmluZyB0aGF0IHRoZSBkYXRhIGNhbiBvbmx5IGJlIA0KICAgdXNl ZCBieSB0aG9zZSBhdXRob3JpemVkOyBoZW5jZSB0aGUgbmVlZCBmb3IgY29uZmlkZW50aWFsaXR5 LiANCiAgICANCiAgIEludGVybmFsIHRvIHRoZSBidW5kbGUtYXdhcmUgb3ZlcmxheSBuZXR3b3Jr LCB0aGUgYnVuZGxlIG5vZGVzIHNob3VsZCANCiAgIGJlIGNvbmNlcm5lZCB3aXRoIHRoZSBhdXRo ZW50aWNpdHkgb2Ygb3RoZXIgYnVuZGxlIG5vZGVzIGFzIHdlbGwgYXMgDQogICB0aGUgcHJlc2Vy dmF0aW9uIG9mIGJ1bmRsZSBwYXlsb2FkIGRhdGEgaW50ZWdyaXR5IGFzIGl0IGlzIGZvcndhcmRl ZCANCiAgIGJldHdlZW4gYnVuZGxlIG5vZGVzLiANCiAgICANCiAgIEFzIGEgcmVzdWx0LCBidW5k bGUgc2VjdXJpdHkgaXMgY29uY2VybmVkIHdpdGggdGhlIGF1dGhlbnRpY2l0eSwgDQogICBpbnRl Z3JpdHksIGFuZCBjb25maWRlbnRpYWxpdHkgb2YgYnVuZGxlcyBjb252ZXllZCBhbW9uZyBidW5k bGUgDQogICBub2Rlcy4gIFRoaXMgaXMgYWNjb21wbGlzaGVkIHZpYSB0aGUgdXNlIG9mIHRocmVl LCBpbmRlcGVuZGVudCANCiAgIHNlY3VyaXR5IHNwZWNpZmljIGJ1bmRsZSBibG9ja3Mgd2hpY2gg bWF5IGJlIHVzZWQgdG9nZXRoZXIgdG8gcHJvdmlkZSANCiAgIG11bHRpcGxlIGJ1bmRsZSBzZWN1 cml0eSBzZXJ2aWNlcyBvciBpbmRlcGVuZGVudGx5IG9mIG9uZSBhbm90aGVyLCANCiAgIGRlcGVu ZGluZyBvbiBwZXJjZWl2ZWQgc2VjdXJpdHkgdGhyZWF0cywgbWFuZGF0ZWQgc2VjdXJpdHkgDQog ICByZXF1aXJlbWVudHMsIGFuZCBzZWN1cml0eSBwb2xpY2llcyB0aGF0IG11c3QgYmUgZW5mb3Jj ZWQuIA0KICAgIA0KICAgVGhlIEJ1bmRsZSBBdXRoZW50aWNhdGlvbiBCbG9jayAoQkFCKSBlbnN1 cmVzIHRoZSBhdXRoZW50aWNpdHkgYW5kIA0KICAgaW50ZWdyaXR5IG9mIGJ1bmRsZXMgb24gYSBo b3AtYnktaG9wIGJhc2lzIGJldHdlZW4gYnVuZGxlIG5vZGVzLiAgVGhlIA0KICAgQkFCIGFsbG93 cyBlYWNoIGJ1bmRsZSBub2RlIHRvIHZlcmlmeSBhIGJ1bmRsZSdzIGF1dGhlbnRpY2l0eSBiZWZv cmUgDQogICBwcm9jZXNzaW5nIG9yIGZvcndhcmRpbmcgdGhlIGJ1bmRsZS4gIEluIHRoaXMgd2F5 LCBlbnRpdGllcyB0aGF0IGFyZSANCiAgIG5vdCBhdXRob3JpemVkIHRvIHNlbmQgYnVuZGxlcyB3 aWxsIGhhdmUgdW5hdXRob3JpemVkIHRyYW5zbWlzc2lvbnMgDQogICBibG9ja2VkIGJ5IHNlY3Vy aXR5LWF3YXJlIGJ1bmRsZSBub2Rlcy4gDQogICAgDQogICBBZGRpdGlvbmFsbHksIHRvIHByb3Zp ZGUgInNlY3VyaXR5LXNvdXJjZSIgdG8gInNlY3VyaXR5LWRlc3RpbmF0aW9uIiANCiAgIGJ1bmRs ZSBhdXRoZW50aWNpdHkgYW5kIGludGVncml0eSwgdGhlIFBheWxvYWQgU2VjdXJpdHkgQmxvY2sg KFBTQikgDQogICBpcyB1c2VkLiAgQSAic2VjdXJpdHktc291cmNlIiBtYXkgbm90IGFjdHVhbGx5 IGJlIHRoZSBvcmlnaW5hdGlvbiANCiAgIHBvaW50IG9mIHRoZSBidW5kbGUgYnV0IGluc3RlYWQg bWF5IGJlIHRoZSBmaXJzdCBwb2ludCBhbG9uZyB0aGUgcGF0aCANCiAgIHRoYXQgaXMgc2VjdXJp dHktYXdhcmUgYW5kIGlzIGFibGUgdG8gYXBwbHkgc2VjdXJpdHkgc2VydmljZXMuICBGb3IgDQog ICBleGFtcGxlLCBhbiBlbmNsYXZlIG9mIG5ldHdvcmtlZCBzeXN0ZW1zIG1heSBnZW5lcmF0ZSBi dW5kbGVzIGJ1dCANCiAgIG9ubHkgdGhlaXIgZ2F0ZXdheSBtYXkgYmUgcmVxdWlyZWQgYW5kL29y IGFibGUgdG8gYXBwbHkgc2VjdXJpdHkgDQogICBzZXJ2aWNlcy4gIFRoZSBQU0IgYWxsb3dzIGFu eSBzZWN1cml0eS1lbmFibGVkIGVudGl0eSBhbG9uZyB0aGUgDQogICBkZWxpdmVyeSBwYXRoLCBp biBhZGRpdGlvbiB0byB0aGUgInNlY3VyaXR5LWRlc3RpbmF0aW9uIiAodGhlIA0KICAgcmVjaXBp ZW50IGNvdW50ZXJwYXJ0IHRvIHRoZSAic2VjdXJpdHktc291cmNlIiksIHRvIGVuc3VyZSB0aGUg DQogICBidW5kbGUncyBhdXRoZW50aWNpdHkuIA0KICAgIA0KICAgRmluYWxseSwgdG8gcHJvdmlk ZSBwYXlsb2FkIGNvbmZpZGVudGlhbGl0eSwgdGhlIHVzZSBvZiB0aGUgDQogICBDb25maWRlbnRp YWxpdHkgQmxvY2sgKENCKSBpcyBhdmFpbGFibGUuICBUaGUgYnVuZGxlIHBheWxvYWQgbWF5IGJl IA0KICAgZW5jcnlwdGVkIHRvIHByb3ZpZGUgInNlY3VyaXR5LXNvdXJjZSIgdG8gInNlY3VyaXR5 LWRlc3RpbmF0aW9uIiANCiAgIHBheWxvYWQgY29uZmlkZW50aWFsaXR5L3ByaXZhY3kuICBUaGUg Q0IgaW5kaWNhdGVzIHRoZSBjcnlwdG9ncmFwaGljIA0KICAgYWxnb3JpdGhtIGFuZCBrZXkgSURz IHRoYXQgd2VyZSB1c2VkIHRvIGVuY3J5cHQgdGhlIHBheWxvYWQuIA0KICAgIA0KICAgTm90ZSB0 aGF0IHJlbW92YWwgb2Ygc3RyaW5ncyBmcm9tIHRoZSBkaWN0aW9uYXJ5IGF0IGEgZ2l2ZW4gcG9p bnQgaW4gDQogICBhIGJ1bmRsZSdzIGVuZC10by1lbmQgcGF0aCwgYW5kIGF0dGVuZGFudCBhZGp1 c3RtZW50IG9mIGVuZHBvaW50IElEIA0KICAgcmVmZXJlbmNlcyBpbiB0aGUgYmxvY2tzIG9mIHRo YXQgYnVuZGxlLCBtYXkgbWFrZSBpdCBuZWNlc3NhcnkgdG8gcmUtDQogICBjb21wdXRlIHZhbHVl cyBpbiBvbmUgb3IgbW9yZSBvZiB0aGUgYnVuZGxlJ3Mgc2VjdXJpdHkgYmxvY2tzLiAgDQogDQog DQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAgICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDcg ICAgW1BhZ2UgMzldIA0KDEludGVybmV0IERyYWZ0ICAgICAgQnVuZGxlIFByb3RvY29sIFNwZWNp ZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0KIA0KIA0KICAgIA0KICAgSW5jbHVzaW9uIG9m IHRoZSBCdW5kbGUgU2VjdXJpdHkgUHJvdG9jb2wgaW4gYW55IEJ1bmRsZSBQcm90b2NvbCANCiAg IGltcGxlbWVudGF0aW9uIGlzIFJFQ09NTUVOREVELiAgVXNlIG9mIHRoZSBCdW5kbGUgU2VjdXJp dHkgUHJvdG9jb2wgDQogICBpbiBCdW5kbGUgUHJvdG9jb2wgb3BlcmF0aW9ucyBpcyBPUFRJT05B TC4gDQogICAgDQo4LiBJQU5BIENvbnNpZGVyYXRpb25zIA0KICAgIA0KICAgVGhlIG5ldyBVbmlm b3JtIFJlc291cmNlIElkZW50aWZpZXIgc2NoZW1lICJkdG4iLCBkZWZpbmVkIGJ5IHRoZSANCiAg IEJ1bmRsZSBQcm90b2NvbCwgd2lsbCBuZWVkIHRvIGJlIGRvY3VtZW50ZWQuIA0KICAgIA0KOS4g ICBOb3JtYXRpdmUgUmVmZXJlbmNlcyANCiAgICANCiAgW1JGQzM5NzhdICAgQnJhZG5lciwgUy4s ICJJRVRGIFJpZ2h0cyBpbiBDb250cmlidXRpb25zIiwgQkNQIDc4LCBSRkMgDQogIDM5NzgsIE1h cmNoIDIwMDUuIA0KICAgDQogIFtSRkMzOTc5XSAgIEJyYWRuZXIsIFMuLCAiSW50ZWxsZWN0dWFs IFByb3BlcnR5IFJpZ2h0cyBpbiBJRVRGIA0KICBUZWNobm9sb2d5IiwgQkNQIDc5LCBSRkMgMzk3 OSwgTWFyY2ggMjAwNS4gDQogICANCiAgW1JGQzM5ODZdICAgVC4gQmVybmVycy1MZWUsIFIuIEZp ZWxkaW5nLCBMLiBNYXNpbnRlciwgIlVuaWZvcm0gDQogIFJlc291cmNlIElkZW50aWZpZXIgKFVS SSk6IEdlbmVyaWMgU3ludGF4IiwgU1REIDY2LCBSRkMgMzk4NiwgSmFuIA0KICAyMDA1LiANCiAg IA0KICBbUkZDMjcxN10gICBQZXRrZSwgUi4gYW5kIEkuIEtpbmcsICJSZWdpc3RyYXRpb24gUHJv Y2VkdXJlcyBmb3IgVVJMIA0KICBTY2hlbWUgTmFtZXMiLCBCQ1AgMzUsIFJGQyAyNzE3LCBOb3Zl bWJlciAxOTk5LiANCiAgICANCjEwLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyANCiAgICANCiAg IFsxXSBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUg UmVxdWlyZW1lbnQgDQogICAgICBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3 IA0KICAgIA0KICAgWzJdIFYuIENlcmYsIGV0LiBhbC4sICJEZWxheS1Ub2xlcmFudCBOZXR3b3Jr IEFyY2hpdGVjdHVyZSwiIHdvcmsgaW4gDQogICAgICBwcm9ncmVzcywgZHJhZnQtaXJ0Zi1kdG5y Zy1hcmNoLTAzLnR4dCwgSnVseSAyMDA1IA0KICAgIA0KICAgWzNdIEYuIFdhcnRobWFuLCAiRGVs YXktVG9sZXJhbnQgTmV0d29ya3MgKERUTnMpOiBBIFR1dG9yaWFsIiwgDQogICAgICBXYXJ0aG1h biBBc3NvY2lhdGVzLCBhdmFpbGFibGUgZnJvbSBodHRwOi8vd3d3LmR0bnJnLm9yZyANCiAgICAN CiAgIFs0XSBNaWxscywgRC4sICJOZXR3b3JrIFRpbWUgUHJvdG9jb2wgKFZlcnNpb24gMykgU3Bl Y2lmaWNhdGlvbiwgDQogICAgICBJbXBsZW1lbnRhdGlvbiBhbmQgQW5hbHlzaXMiLCBSRkMgMTMw NSwgTWFyY2ggMTk5MiANCiAgICANCiAgIFs1XSBTLiBTeW1pbmd0b24sIGV0LiBhbC4sICJCdW5k bGUgU2VjdXJpdHkgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiwiIA0KICAgICAgZHJhZnQtaXJ0Zi1k dG5yZy1idW5kbGUtc2VjdXJpdHktMDAudHh0LCBKdW5lIDIwMDUgDQogICAgDQogICBbNl0gUy4g RmFycmVsbCwgUy4gU3ltaW5ndG9uLCBhbmQgSC4gV2Vpc3MsICJEZWxheS1Ub2xlcmFudCBOZXR3 b3JraW5nIA0KICAgICAgU2VjdXJpdHkgT3ZlcnZpZXcsIiBkcmFmdC1pcnRmLWR0bnJnLXNlYy1v dmVydmlldy0NCiAgICAgIDAwLnR4dCwgU2VwdGVtYmVyIDIwMDUgDQogICAgDQogICBbN10gRS4g Ri4gQXJpYXMgYW5kIEIuIEd1aW5vdCwgQi4sICJDb29yZGluYXRlZCB1bml2ZXJzYWwgdGltZSBV VEM6IA0KICAgICAgaGlzdG9yaWNhbCBiYWNrZ3JvdW5kIGFuZCBwZXJzcGVjdGl2ZXMiIGluIEpv dXJu6WVzIHN5c3RlbWVzIGRlIA0KICAgICAgcmVmZXJlbmNlIHNwYXRpby10ZW1wb3JlbHMgMjAw NCANCiAgICANCgwgDQogDQpLLiBTY290dCBhbmQgUy4gQnVybGVpZ2ggICAgICBFeHBpcmVzIC0g U2VwdGVtYmVyIDIwMDcgICAgW1BhZ2UgNDBdIA0KDEludGVybmV0IERyYWZ0ICAgICAgQnVuZGxl IFByb3RvY29sIFNwZWNpZmljYXRpb24gICAgICAgICBNYXJjaCAyMDA3IA0KIA0KIA0KICAgWzhd IEsuIEZhbGwsICIgQSBEZWxheS1Ub2xlcmFudCBOZXR3b3JrIEFyY2hpdGVjdHVyZSBmb3IgQ2hh bGxlbmdlZCANCiAgICAgIEludGVybmV0cyIsIFNJR0NPTU0gMjAwMyANCiAgICANCiAgIFs5XSBB YnN0cmFjdCBTeW50YXggTm90YXRpb24gT25lIChBU04uMSksICJBU04uMSBFbmNvZGluZyBSdWxl czogDQogICAgICBTcGVjaWZpY2F0aW9uIG9mIEJhc2ljIEVuY29kaW5nIFJ1bGVzIChCRVIpLCBD YW5vbmljYWwgRW5jb2RpbmcgDQogICAgICBSdWxlcyAoQ0VSKSBhbmQgRGlzdGluZ3Vpc2hlZCBF bmNvZGluZyBSdWxlcyAoREVSKSIsIElUVS1UIFJlYy4gDQogICAgICBYLjY5MCAoMjAwMikgfCBJ U08vSUVDIDg4MjUtMToyMDAyIA0KICAgIA0KQWNrbm93bGVkZ2VtZW50cyANCiANCiAgIFRoZSBh dXRob3JzIGdyYXRlZnVsbHkgYWNrbm93bGVkZ2UgdGhlIGNvbnRyaWJ1dGlvbnMgb2YgRHIuIFZp bnQgQ2VyZiANCiAgIG9mIEdvb2dsZSwgRHIuIEtldmluIEZhbGwgb2YgSW50ZWwgQ29ycG9yYXRp b24sIE1pY2hhZWwgRGVtbWVyIG9mIHRoZSANCiAgIFVuaXZlcnNpdHkgIG9mICBDYWxpZm9ybmlh ICBhdCAgQmVya2VsZXksICBBZHJpYW4gIEhvb2tlICBhbmQgIExlaWdoIA0KICAgVG9yZ2Vyc29u IG9mIHRoZSBKZXQgUHJvcHVsc2lvbiBMYWJvcmF0b3J5LCBTdGVwaGVuIEZhcnJlbGwgb2YgDQog ICBUcmluaXR5IENvbGxlZ2UgRHVibGluLCBhbmQgUm9iZXJ0IER1cnN0IGFuZCBTdXNhbiBTeW1p bmd0b24gb2YgVGhlIA0KICAgTUlUUkUgQ29ycG9yYXRpb24uICBUaGFua3MgdG8gSG93YXJkIFdl aXNzIG9mIFNQQVJUQSwgSW5jLiwgZm9yIHRoZSANCiAgIHRleHQgb2Ygc2VjdGlvbiA3IGFuZCB0 byBNYW5pa2FudGFuIFJhbWFkYXMgb2YgT2hpbyBVbml2ZXJzaXR5IGZvciANCiAgIG1vc3QgIG9m ICB0aGUgIHRleHQgIG9mICBzZWN0aW9uICAzLjEsICB3aGljaCAgaXMgIGFkYXB0ZWQgIGZyb20g IHRoZSANCiAgIHNwZWNpZmljYXRpb24gZm9yIHRoZSBMaWNrbGlkZXIgVHJhbnNtaXNzaW9uIFBy b3RvY29sLiANCiAgICANCkF1dGhvcidzIEFkZHJlc3NlcyANCiAgICANCiAgIERyLiBLZWl0aCBM LiBTY290dCAgICAgICAgICAgICAgU2NvdHQgQy4gQnVybGVpZ2ggDQogICBUaGUgTUlUUkUgQ29y cG9yYXRpb24gICAgICAgICAgIEpldCBQcm9wdWxzaW9uIExhYm9yYXRvcnkgDQogICA3NTE1IENv bHNoaXJlIERyaXZlICAgICAgICAgICAgIDQ4MDAgT2FrIEdyb3ZlIERyaXZlIA0KICAgTS9TOiBI MzQwICAgICAgICAgICAgICAgICAgICAgICBNL1M6IDE3OS0yMDYgDQogICBNY0xlYW4sIFZBIDIy MTAyICAgICAgICAgICAgICAgIFBhc2FkZW5hLCBDQSA5MTEwOS04MDk5IA0KICAgVGVsZXBob25l ICsxICg3MDMpIDk4My02NTQ3ICAgICBUZWxlcGhvbmUgKzEgKDgxOCkgMzkzLTMzNTMgDQogICBG QVggKzEgKDcwMykgOTgzLTcxNDIgICAgICAgICAgIEZBWCArMSAoODE4KSAzNTQtMTA3NSANCiAg IEVtYWlsIGtzY290dEBtaXRyZS5vcmcgICAgICAgICAgRW1haWwgU2NvdHQuQnVybGVpZ2hAanBs Lm5hc2EuZ292ICANCiAgICANCiAgUGxlYXNlIHJlZmVyIGNvbW1lbnRzIHRvIGR0bi1pbnRlcmVz dEBtYWlsbWFuLmR0bnJnLm9yZy4gIFRoZSBEZWxheSANCiAgVG9sZXJhbnQgTmV0d29ya2luZyBS ZXNlYXJjaCBHcm91cCAoRFROUkcpIHdlYiBzaXRlIGlzIGxvY2F0ZWQgYXQgDQogIGh0dHA6Ly93 d3cuZHRucmcub3JnLiANCiANCkNvcHlyaWdodCBOb3RpY2UgIA0KIA0KICAgQ29weXJpZ2h0IChD KSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg DQogICB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBp biBCQ1AgNzgsIGFuZCANCiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhv cnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMuIA0KICAgIA0KRGlzY2xhaW1lciANCiANCiAgVGhp cyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3Zp ZGVkIG9uIGFuIA0KICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdB TklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMgDQogIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5Z KSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCANCiAgRU5HSU5FRVJJTkcg VEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCAN CiANCiANCksuIFNjb3R0IGFuZCBTLiBCdXJsZWlnaCAgICAgIEV4cGlyZXMgLSBTZXB0ZW1iZXIg MjAwNyAgICBbUGFnZSA0MV0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICBCdW5kbGUgUHJvdG9jb2wg U3BlY2lmaWNhdGlvbiAgICAgICAgIE1hcmNoIDIwMDcgDQogDQogDQogIElOQ0xVRElORyBCVVQg Tk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgDQogIElORk9S TUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVE IA0KICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJ Q1VMQVIgUFVSUE9TRS4gDQogICAgDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgDQogICAgDQogIFRo ZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUg b2YgYW55IA0KICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0 aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8gDQogIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9u IG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gDQogIHRoaXMgZG9jdW1lbnQg b3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyANCiAg bWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRo YXQgaXQgaGFzIA0KICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55 IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24gDQogIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVz cGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUgDQogIGZvdW5kIGluIEJDUCA3 OCBhbmQgQkNQIDc5LiANCiAgIA0KICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8g dGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueSANCiAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0 byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiANCiAgYXR0ZW1wdCBtYWRl IHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9m IA0KICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2Yg dGhpcyANCiAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1s aW5lIElQUiByZXBvc2l0b3J5IGF0IA0KICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4gIA0KICAg DQogIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRz IGF0dGVudGlvbiBhbnkgDQogIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0 aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkgDQogIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNo bm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudCAgDQogIHRoaXMgc3RhbmRh cmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQgaWV0Zi0g DQogIGlwckBpZXRmLm9yZy4gDQogICAgDQogICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KIA0KIA0KSy4gU2NvdHQgYW5kIFMuIEJ1cmxlaWdoICAgICAgRXhw aXJlcyAtIFNlcHRlbWJlciAyMDA3ICAgIFtQYWdlIDQyXSANCgw= ------_=_NextPart_001_01C7665C.E4EC001B-- Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2DLWZY06001 for ; Tue, 13 Mar 2007 13:32:38 -0800 Received: from p5b03b826.dip0.t-ipconnect.de ([91.3.184.38] helo=[192.168.0.188]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HREbX-0001XK-QE; Tue, 13 Mar 2007 22:32:24 +0100 Message-ID: <45F71865.3000609@cs.uni-goettingen.de> Date: Tue, 13 Mar 2007 22:32:21 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: hipsec-rg@listserv.cybertrust.com, mobopts@irtf.org, dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Subject: [dtn-interest] CFP: MobiArch 2007 at ACM SIGCOMM 2007, Kyoto, Japan Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: (Please accept our apologies if you have received multiple copies.) -------------------------------------------------------------------- The Second International Workshop on Mobility in the Evolving Internet Architecture (MobiArch 2007) Kyoto, Japan, August 27, 2007 Sponsored by ACM SIGCOMM In-Cooperation with ACM SIGMOBILE (to be held with ACM SIGCOMM 2007, August 27-31, 2007) http://user.informatik.uni-goettingen.de/~mobiarch/2007 -------------------------------------------------------------------- Important Dates: =============== Abstract registration: March 20, 2007 Submission Deadline: March 27, 2007 Acceptance Notification: May 15, 2007 Camera-ready version due: June 12, 2007 MobiArch'07 Workshop: August 27, 2007 SIGCOMM'07: August 27-31, 2007 Call for Papers: =============== With the recent development of technologies in wireless access and mobile devices, user, terminal, and network mobility has become an indispensable component of today's Internet vision, and it is likely to continue in the near future, while affecting the whole architectural design of the future Internet. Yet, issues like efficient mobility management and optimization, locator-identifier split, multihoming, security, and related operational/deployment concerns are still in their early stages of development. Moreover, the Internet architecture, its end-to-end principles, and business models will require rethinking due to the massive penetration of mobility into the Internet. MobiArch'07 welcomes submissions, from both researchers and practitioners, in exploration of recent advances in architectures, protocols, and experiences with emerging technologies on wireless and mobility over the Internet, with an emphasis on wireless infrastructures and mobility patterns for mobility support, new mobility protocols, service discovery, routing and location management, mobile network performance evaluation and modeling, multi-homing, security, architectural impacts and deployment considerations. Topics of Interest: ================== Topics of MobiArch’07 cover all aspects of architectural issues and system support for wireless and mobility in the Internet, including but not limited to: - Impacts of new wireless technologies/services and mobility patterns on the Internet architecture - Architectures and protocols for mobility support in the Internet, ranging from approaches in link, network, transport to session/application layers and cross-layer design - Location management, positioning and data management systems for wireless and mobility - Routing and addressing, including locator/identifier split issues and their impacts to the Internet architecture - IP multihoming including flow distribution and load sharing for wireless and mobility - Performance evaluation, experimentation and modeling of mobility in the Internet - Accounting, access control, security and privacy issues and impacts to Internet architecture - Economic, scalability and deployment issues of mobility infrastructure design - Mechanisms and issues with connecting developing regions into the Internet Following the success of MobiArch'06, the MobiArch'07 workshop will be a single-track one-day workshop. Early stages, position papers, systems and measurement papers will be particularly welcome. The proceedings will be published by the ACM and ACM digital library. Submissions: =========== Submissions must be made to MobiArch'07 EDAS entry: http://edas.info/5238, following the guidelines in MobiArch'07 webpage: http://user.informatik.uni-goettingen.de/~mobiarch/2007 PROGRAM CO-CHAIRS ================= Xiaoming Fu, University of Goettingen (Germany) Katherine Guo, Bell Labs (USA) Sue Moon, KAIST (Korea) Ryuji Wakikawa, Keio University (Japan) PROGRAM COMMITTEE ================= Rui Aguiar, Universidade de Aveiro (Portugal) Jari Arkko, Ericsson (Finland) Song Chong, KAIST (Korea) Lars Eggert, NEC Europe Labs (Germany) Joseph Evans, U. Kansas (USA) Serge Fdida, University Pierre & Marie Curie (Paris 6) (France) Ivano Guardini, Telecom Italia Lab (IT) Seung-Jae Han, Yonsei U (Korea) Rajeev Koodli, Nokia Research Center (USA) Stefan Mangold, Swisscom (Switzerland) Thomas Noel, Universite Strasbourg (France) Joerg Ott, Helsinki U of Techology (Finland) Charles Perkins, Nokia Research Center (USA) Injong Rhee, NC State University (USA) Henning Schulzrinne, Columbia U. (USA) Peter Steenkiste, CMU (USA) Hideaki Sunahara, NARA Inst. of Sci. & Tech. (Japan) Fumio Teraoka, Keio U. (Japan) Hannes Tschofenig, Siemens (Germany) Andras Veres, Ericsson (Hungary) Kenichi Yamazaki, NTT Docomo (Japan) Lixia Zhang, UCLA (USA) Yongguang Zhang, Microsoft Research Asia (China) PUBLICITY CHAIR =============== Jon Crowcroft, University of Cambridge (UK) QUESTIONS ========= Please consult the Program Co-Chairs (mobiarch@informatik.uni-goettingen.de) if you are uncertain whether your paper falls within the scope of the workshop. Received: from smtp.iit.cnr.it (mx3.iit.cnr.it [146.48.98.150]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2CHYYY21102 for ; Mon, 12 Mar 2007 09:34:35 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id E6EA723DC28 for ; Mon, 12 Mar 2007 18:34:25 +0100 (CET) Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx3.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20979-05 for ; Mon, 12 Mar 2007 18:34:24 +0100 (CET) Received: from [146.48.99.95] (dhcp32.iit.cnr.it [146.48.99.95]) by smtp.iit.cnr.it (Postfix) with ESMTP id 692E823DC1C for ; Mon, 12 Mar 2007 18:34:24 +0100 (CET) Message-ID: <45F58F0D.5080606@iit.cnr.it> Date: Mon, 12 Mar 2007 18:34:05 +0100 From: Chiara Boldrini User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Debian amavisd-new at mx3.iit.cnr.it Subject: [dtn-interest] ACM/SIGMOBILE MOBIOPP 2007: Deadline is fast approaching! Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: ------------------------------------------------------------------------ ***** PAPER SUBMISSION DEADLINE IS FAST APPROACHING ***** *** JUST 3 DAYS LEFT *** MARCH 15, 2007 (11:59pm PST) ------------------------------------------------------------------------ CALL FOR PAPERS First International Workshop on Mobile Opportunistic Networking MobiOpp 2007 sponsored by ACM/SIGMOBILE in conjunction with ACM MobiSys 2007 http://cnd.iit.cnr.it/mobiopp07 jointly organized by IIT-CNR, Italy UCLA, USA June 11, 2007 Puerto Rico, USA Opportunistic Networks are one of the most exciting evolutions of the legacy Mobile Ad hoc Networking (MANET) paradigm, in which the assumption of complete paths between data senders and receivers is released. Opportunistic Networks enable users' communication in disconnected environments, in which island of connected devices appear, disappear, and reconfigure dynamically. The network is thus extremely dynamic, and is formed by the evolving contacts among mobile devices, and among connected clouds of devices. In this view, legacy-Internet connectivity is just a particular connectivity opportunity. Opportunistic Networks thus encompass the features and methods of delay or disruption tolerant networks (DTN). They are very suitable to support the pervasive networking scenario, in which a huge number of devices carried by users and embedded in the environment communicate wirelessly without requiring any pre-existing infrastructure. By enabling end-to-end communication without requiring complete paths, Opportunistic Networks are much closer to real pervasive networking scenarios, with respect to the legacy MANET paradigm. Original contributions are solicited, related to systems and protocols design, development and analysis, in all areas related to Opportunistic Networking. Topics of interest include, but are not limited to: * Architectures for opportunistic networks * (Killer) applications for opportunistic networks * Middleware services in opportunistic networks * Dissemination and replication techniques for opportunistic networks * Resource management techniques for opportunistic networks * Transport and reliability issues in opportunistic networks * Routing issues in opportunistic networks * Wireless link design and optimisation for opportunistic networks * Opportunistic Networking in Wireless Sensor Networks * Security issues in opportunistic networks * Trust and cooperation in opportunistic networks * Mobility models for opportunistic networks * Tools and techniques for designing, analyzing and building opp. networks * Opportunistic networks testbeds and measurements * Opportunistic networks performance modeling PAPER SUBMISSION AND PUBLICATION Papers must not be already under submission for any other publication. Paper submissions for regular papers must be limited to 8 pages including text, figures, references, and appendices; single- or double-column are fine for submissions. The font size used in the text of your submission must not be smaller than 10 points. Papers significantly exceeding the maximum length of 8 pages will be automatically rejected. Submission implies the willingness of at least one author to attend the workshop and present the paper. PLEASE CHECK OUT THE WORKSHOP WEBSITE (http://cnd.iit.cnr.it/mobiopp07) FOR THE COMPLETE INSTRUCTIONS. Extended versions of workshop selected papers will be considered for possible fast track publication on the Pervasive and Mobile Computing Journal (Elsevier). IMPORTANT DATES Paper Submission March 7, 2007 ****** EXTENDED TO MARCH 15, 2007 (11:59pm PST) ******* Notification April 15, 2007 Camera-ready due April 25, 2007 Workshop date June 11, 2007 ORGANISING COMMITTEE General Co-Chairs Marco Conti IIT-CNR, Italy marco.conti@iit.cnr.it Mario Gerla UCLA, USA gerla@cs.ucla.edu Program Co-Chairs Andrea Passarella IIT-CNR, Italy a.passarella@iit.cnr.it Giovanni Pau UCLA, USA gpau@cs.ucla.edu STEERING COMMITTEE Marco Conti, IIT-CNR, Italy Jon Crowcroft, University of Cambridge, UK Mario Gerla, UCLA, USA Mani Srivastava, UCLA, USA PUBLICITY CHAIR Chiara Boldrini, IIT-CNR, Italy TECHNICAL PROGRAM COMMITTEE Mostafa Ammar, Georgia Institute of Technology, USA Giuseppe Anastasi, University of Pisa, Italy Levente Buttyan, BUTE, Hungary Tracy Camp, Colorado School of Mines, USA Jiannong Cao, The HK Polytechnic University, Hong Kong Augustin Chaintreau, Thomson, France Ling-Jyh Chen, Academia Sinica, Taiwan Serge Fdida, University Pierre et Marie Curie, France Silvia Giordano, SUPSI, Switzerland Per Gunningberg, Uppsala University, Sweden Srinivasan Keshav, University of Waterloo, CA Jean-Yves Le Boudec, EPFL, CH Vincent Lenders, Princeton University, USA Brian Levine, University of Massachusetts at Amherst, USA Christoph Lindemann, University of Leipzig, Germany Margaret Martonosi, Princeton University, USA Cecilia Mascolo, University College London, UK Kenichi Mase, Niigata University, Japan Martin May, ETH, Switzerland Refik Molva, Eurecom, France Lionel Ni, The HK University of Science and Technology, Hong Kong Joerg Ott, Helsinki University of Technology, Finland Kaustubh Phanse, Uppsala University, Sweden Konstantinos Psounis, University of Southern California, USA Chunming Qiao, State University of New York at Buffalo, USA Christian Rohner, Uppsala University, Sweden Ant Rowstron, Microsoft Research, UK Kave' Salamatian, EPFL, Switzerland Mani B. Srivastava, UCLA, USA Violet Syrotiuk, Arizona State University, USA Eiko Yoneki, University of Cambridge, UK Ellen W. Zegura, Georgia Institute of Technology, USA -- ==================================================== Chiara Boldrini MobiOpp 2007 Publicity Chair Institute for Informatics and Telematics (IIT) Italian National Research Council (CNR) Via G. Moruzzi, 1 - 56124 Pisa, Italy phone: + 39 050 315 3504 (direct) email: chiara.boldrini@iit.cnr.it ==================================================== Received: from joe.tiscali.it (joe.tiscali.it [213.205.33.54]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l29A6KY03634 for ; Fri, 9 Mar 2007 02:06:20 -0800 Received: from [192.168.1.30] (84.222.31.153) by joe.tiscali.it (7.2.079) id 45E582FD0015DA89 for dtn-interest@mailman.dtnrg.org; Fri, 9 Mar 2007 11:06:11 +0100 Message-ID: <45F13193.7060505@email.it> Date: Fri, 09 Mar 2007 11:06:11 +0100 From: POIX Reply-To: poix@email.it User-Agent: Mozilla Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [dtn-interest] dtnsim2 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi everybody, I get stuck to make simulation with dtnsim2. I haven't clear which are the steps to make simulation, how to create sim.fl, sim.file, inp_graph_file.gr and how to use it. Please, could you send me some examples and instructions? Beste regards, Gianni Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l297G2Y02506 for ; Thu, 8 Mar 2007 23:16:02 -0800 Received: by ug-out-1314.google.com with SMTP id 71so1158736ugh for ; Thu, 08 Mar 2007 23:16:00 -0800 (PST) Received: by 10.67.101.10 with SMTP id d10mr8856400ugm.1173424560841; Thu, 08 Mar 2007 23:16:00 -0800 (PST) Received: from ?192.168.1.30? ( [84.222.31.153]) by mx.google.com with ESMTP id u9sm5688396muf.2007.03.08.23.15.59; Thu, 08 Mar 2007 23:16:00 -0800 (PST) Message-ID: <45F109AE.1000406@cattonclub.it> Date: Fri, 09 Mar 2007 08:15:58 +0100 From: Gianni Cattoni Reply-To: gianni@cattonclub.it User-Agent: Mozilla Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [dtn-interest] dtnsim2 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi everybody, I get stuck to make simulation with dtnsim2. I haven't clear which are the steps to make simulation, how to create sim.fl, sim.file, inp_graph_file.gr and how to use it. Please, could you send me some examples and instructions? Beste regards, Gianni Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l28LGVY29513 for ; Thu, 8 Mar 2007 13:16:32 -0800 Received: by ug-out-1314.google.com with SMTP id 71so1028760ugh for ; Thu, 08 Mar 2007 13:16:26 -0800 (PST) Received: by 10.67.100.17 with SMTP id c17mr7808578ugm.1173388586273; Thu, 08 Mar 2007 13:16:26 -0800 (PST) Received: from ?192.168.1.30? ( [84.222.31.153]) by mx.google.com with ESMTP id u9sm3987855muf.2007.03.08.13.16.24; Thu, 08 Mar 2007 13:16:25 -0800 (PST) Message-ID: <45F07D26.2060209@cattonclub.it> Date: Thu, 08 Mar 2007 22:16:22 +0100 From: Gianni Cattoni Reply-To: gianni@cattonclub.it User-Agent: Mozilla Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org, dtn-interest-admin@mailman.dtnrg.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [dtn-interest] dtnsim2 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi everybody, I get stuck to make simulation with dtnsim2. I haven't clear which are the steps to make simulation, how to create sim.fl, sim.file, inp_graph_file.gr and how to use it. Please, could you send me some examples and instructions? Beste regards, Gianni Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l28HcFY27891 for ; Thu, 8 Mar 2007 09:38:16 -0800 Received: by nf-out-0910.google.com with SMTP id p48so681981nfa for ; Thu, 08 Mar 2007 09:38:14 -0800 (PST) Received: by 10.82.175.2 with SMTP id x2mr1158473bue.1173375494048; Thu, 08 Mar 2007 09:38:14 -0800 (PST) Received: from ?192.168.1.30? ( [84.222.31.153]) by mx.google.com with ESMTP id g8sm5074530muf.2007.03.08.09.38.12; Thu, 08 Mar 2007 09:38:13 -0800 (PST) Message-ID: <45F04A03.6000907@cattonclub.it> Date: Thu, 08 Mar 2007 18:38:11 +0100 From: Gianni Cattoni Reply-To: gianni@cattonclub.it User-Agent: Mozilla Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [dtn-interest] dtnsim2 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi everybody, I get stuck to make simulation with dtnsim2. I haven't clear which are the steps to make simulation, how to create sim.fl, sim.file, inp_graph_file.gr and how to use it. Please, could you send me some examples and instructions? Beste regards, Gianni Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l27DOkY16617 for ; Wed, 7 Mar 2007 05:24:47 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id AB82D68018 for ; Wed, 7 Mar 2007 13:24:40 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A01F41A83F9; Wed, 07 Mar 2007 13:24:40 +0000 Received: from [134.226.36.174] (nanga.dsg.cs.tcd.ie [134.226.36.174]) by imx2.tcd.ie (Postfix) with ESMTP id 98ED568018 for ; Wed, 7 Mar 2007 13:24:40 +0000 (GMT) Message-ID: <45EEBD69.3050207@cs.tcd.ie> Date: Wed, 07 Mar 2007 13:26:01 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: DTN Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A11F41A83F9 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.66.1) Subject: [dtn-interest] Dublin meeting... Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi All, A few of you may need a visa to come to Dublin. There's some info at [1] about that. If you need a letter of invitation, there's one at [2]. Let me know if I can help, Cheers, Stephen. [1] http://www.dfa.ie/home/index.aspx?id=8605 [2] https://down.dsg.cs.tcd.ie/misc/dtnrg-invite.pdf Received: from inachos.supaero.fr (inachos.supaero.fr [134.212.190.5]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l278jmY12502 for ; Wed, 7 Mar 2007 00:45:48 -0800 Received: from tyr.supaero.fr (fenris.supaero.fr [134.212.178.14]) by inachos.supaero.fr (8.13.8/8.13.8/ONERA-SRI) with ESMTP id l278jjE3020594 for ; Wed, 7 Mar 2007 09:45:45 +0100 Received: from tyr.supaero.fr (fenris.antiviral [127.0.0.1]) by tyr.supaero.fr (8.13.8/8.13.8/ONERA-SRI) with ESMTP id l278jjdb015919 for ; Wed, 7 Mar 2007 09:45:45 +0100 Received: from [192.168.1.2] (chouffe.supaero.fr [134.212.136.232]) by tyr.supaero.fr (8.13.8/8.13.8/ONERA-SRI) with ESMTP id l278iLP2015762 for ; Wed, 7 Mar 2007 09:44:41 +0100 Message-ID: <45EE7B38.6030603@enst.fr> Date: Wed, 07 Mar 2007 09:43:36 +0100 From: Laurent FRANCK User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (inachos.supaero.fr [134.212.190.5]); Wed, 07 Mar 2007 09:45:45 +0100 (CET) X-Spam-Status: No, score=-3.1 required=6.5 tests=ALL_TRUSTED,BAYES_00,INFO_TLD autolearn=ham version=3.1.3-supaero_onesri_2 X-Spam-Checker-Version: SpamAssassin 3.1.3-supaero_onesri_2 (2006-06-01) on inachos.supaero.fr Subject: [dtn-interest] IWSSC'07 - Special session on DTN via satellite - submission now open Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: -- Apologies if you receive multiple copies of this message -- Special session "Delay Tolerant Networking via Satellites" International Workshop on Satellite and Space Communications 2007 IWSSC'2007 - 13-14 September 2007 - Salzburg - Austria http://iwssc2007.sbg.ac.at/ * Paper submission is now open through EDAS * http://www.edas.info Note: a dedicated track is created under EDAS for this session. Should you plan to submit, please contact beforehand: Laurent.Franck@enst-bretagne.fr Application fields for DTN are: * Deep space communication * Sensor networks via satellites * Satellite based disaster recovery communication * Satellite based sparse mobile networks and others Possible topics are: * Store and forward routing * Multicasting in degraded conditions * Convergence layers * Security services without TTP * Adaptive coding * DTN on unidirectional links and others Thank you for submitting to IWSSC'07 ! -- Laurent Franck - Assoc. Prof. ENST Bretagne / Site of Toulouse 10 Av. Edouard Belin BP40004 F-31028 Toulouse Cedex 4 FRANCE Tel://+33 5 62 17 83 67 http://www.f4dwu.net B4B9 37DD 3491 EEAF 076B 1810 5F73 9074 898D 2DD3 Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l2692hY01723 for ; Tue, 6 Mar 2007 01:02:44 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 7340C12EDBC for ; Tue, 6 Mar 2007 10:02:40 +0100 (CET) Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14671-08 for ; Tue, 6 Mar 2007 10:02:38 +0100 (CET) Received: from [146.48.99.95] (dhcp32.iit.cnr.it [146.48.99.95]) by smtp.iit.cnr.it (Postfix) with ESMTP id 6B6E612EDBA for ; Tue, 6 Mar 2007 10:02:38 +0100 (CET) Message-ID: <45ED3C2E.9070302@iit.cnr.it> Date: Tue, 06 Mar 2007 11:02:22 +0100 From: Chiara Boldrini User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it Subject: [dtn-interest] ACM/SIGMOBILE MOBIOPP 2007: Deadline Extension Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: - Our apologies if you receive multiple copies of this CFP - ------------------------------------------------------------------------ ***** PAPER SUBMISSION DEADLINE HAS BEEN EXTENDED TO ***** MARCH 15, 2007 (11:59pm PST) ------------------------------------------------------------------------ CALL FOR PAPERS First International Workshop on Mobile Opportunistic Networking MobiOpp 2007 sponsored by ACM/SIGMOBILE in conjunction with ACM MobiSys 2007 http://cnd.iit.cnr.it/mobiopp07 jointly organized by IIT-CNR, Italy UCLA, USA June 11, 2007 Puerto Rico, USA Opportunistic Networks are one of the most exciting evolutions of the legacy Mobile Ad hoc Networking (MANET) paradigm, in which the assumption of complete paths between data senders and receivers is released. Opportunistic Networks enable users' communication in disconnected environments, in which island of connected devices appear, disappear, and reconfigure dynamically. The network is thus extremely dynamic, and is formed by the evolving contacts among mobile devices, and among connected clouds of devices. In this view, legacy-Internet connectivity is just a particular connectivity opportunity. Opportunistic Networks thus encompass the features and methods of delay or disruption tolerant networks (DTN). They are very suitable to support the pervasive networking scenario, in which a huge number of devices carried by users and embedded in the environment communicate wirelessly without requiring any pre-existing infrastructure. By enabling end-to-end communication without requiring complete paths, Opportunistic Networks are much closer to real pervasive networking scenarios, with respect to the legacy MANET paradigm. Original contributions are solicited, related to systems and protocols design, development and analysis, in all areas related to Opportunistic Networking. Topics of interest include, but are not limited to: * Architectures for opportunistic networks * (Killer) applications for opportunistic networks * Middleware services in opportunistic networks * Dissemination and replication techniques for opportunistic networks * Resource management techniques for opportunistic networks * Transport and reliability issues in opportunistic networks * Routing issues in opportunistic networks * Wireless link design and optimisation for opportunistic networks * Opportunistic Networking in Wireless Sensor Networks * Security issues in opportunistic networks * Trust and cooperation in opportunistic networks * Mobility models for opportunistic networks * Tools and techniques for designing, analyzing and building opp. networks * Opportunistic networks testbeds and measurements * Opportunistic networks performance modeling PAPER SUBMISSION AND PUBLICATION Papers must not be already under submission for any other publication. Paper submissions for regular papers must be limited to 8 pages including text, figures, references, and appendices; single- or double-column are fine for submissions. The font size used in the text of your submission must not be smaller than 10 points. Papers significantly exceeding the maximum length of 8 pages will be automatically rejected. Submission implies the willingness of at least one author to attend the workshop and present the paper. PLEASE CHECK OUT THE WORKSHOP WEBSITE (http://cnd.iit.cnr.it/mobiopp07) FOR THE COMPLETE INSTRUCTIONS. Extended versions of workshop selected papers will be considered for possible fast track publication on the Pervasive and Mobile Computing Journal (Elsevier). IMPORTANT DATES Paper Submission March 7, 2007 ****** EXTENDED TO MARCH 15, 2007 (11:59pm PST) ******* Notification April 15, 2007 Camera-ready due April 25, 2007 Workshop date June 11, 2007 ORGANISING COMMITTEE General Co-Chairs Marco Conti IIT-CNR, Italy marco.conti@iit.cnr.it Mario Gerla UCLA, USA gerla@cs.ucla.edu Program Co-Chairs Andrea Passarella IIT-CNR, Italy a.passarella@iit.cnr.it Giovanni Pau UCLA, USA gpau@cs.ucla.edu STEERING COMMITTEE Marco Conti, IIT-CNR, Italy Jon Crowcroft, University of Cambridge, UK Mario Gerla, UCLA, USA Mani Srivastava, UCLA, USA PUBLICITY CHAIR Chiara Boldrini, IIT-CNR, Italy TECHNICAL PROGRAM COMMITTEE Mostafa Ammar, Georgia Institute of Technology, USA Giuseppe Anastasi, University of Pisa, Italy Levente Buttyan, BUTE, Hungary Tracy Camp, Colorado School of Mines, USA Jiannong Cao, The HK Polytechnic University, Hong Kong Augustin Chaintreau, Thomson, France Ling-Jyh Chen, Academia Sinica, Taiwan Serge Fdida, University Pierre et Marie Curie, France Silvia Giordano, SUPSI, Switzerland Per Gunningberg, Uppsala University, Sweden Srinivasan Keshav, University of Waterloo, CA Jean-Yves Le Boudec, EPFL, CH Vincent Lenders, Princeton University, USA Brian Levine, University of Massachusetts at Amherst, USA Christoph Lindemann, University of Leipzig, Germany Margaret Martonosi, Princeton University, USA Cecilia Mascolo, University College London, UK Kenichi Mase, Niigata University, Japan Martin May, ETH, Switzerland Refik Molva, Eurecom, France Lionel Ni, The HK University of Science and Technology, Hong Kong Joerg Ott, Helsinki University of Technology, Finland Kaustubh Phanse, Uppsala University, Sweden Konstantinos Psounis, University of Southern California, USA Chunming Qiao, State University of New York at Buffalo, USA Christian Rohner, Uppsala University, Sweden Ant Rowstron, Microsoft Research, UK Kave' Salamatian, EPFL, Switzerland Mani B. Srivastava, UCLA, USA Violet Syrotiuk, Arizona State University, USA Eiko Yoneki, University of Cambridge, UK Ellen W. Zegura, Georgia Institute of Technology, USA ==================================================== Chiara Boldrini MobiOpp 2007 Publicity Chair Institute for Informatics and Telematics (IIT) Italian National Research Council (CNR) Via G. Moruzzi, 1 - 56124 Pisa, Italy phone: + 39 050 315 3504 (direct) email: chiara.boldrini@iit.cnr.it ==================================================== Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l22NVSY28625 for ; Fri, 2 Mar 2007 15:31:28 -0800 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 2354A4FEFD; Sat, 3 Mar 2007 01:31:24 +0200 (EET) Message-ID: <45E8A586.70703@netlab.hut.fi> Date: Sat, 03 Mar 2007 00:30:30 +0200 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Durga Prasad Pandey CC: Joerg Ott , Lloyd Wood , stg@student.umass.edu, dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] DTN2 ConvergenceLayers References: <1172767797.45e7043586cbb@mail-www.oit.umass.edu> <200703011731.RAA21937@cisco.com> <45E72191.3050104@netlab.hut.fi> <376BD19D-68A7-470C-9F7E-1B8895FFDFCE@MIT.EDU> <45E72BE6.4030508@netlab.hut.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Durga Prasad Pandey wrote: > On Mar 1, 2007, at 2:39 PM, Joerg Ott wrote: > >>>> Except for the autoconfiguration in ad-hoc mode (since we do not >>>> have IPv6 support yet, I believe). >>> >>> I didn't know autoconf works only with IPv6 support. Am I reading >>> you right? I actually looked up the IETF page for autoconf and it >>> looks like the WG has been sleepy for a while, though I had >>> thought autoconf has been implemented in different systems. >> >> >> Sure, you have autoconf on 169.254/16 but this takes time as nodes have >> pick and then defend addresses -- which may cost precious seconds if >> you are in a rush. > > > I am wondering what the actual delay could be numerically. Given a > wireless(802.11) environment implies that the distance between nodes is > not much really - at this point it usually is less than 100 metres. So > the delay could probably be a few seconds and usually tolerable, but > maybe in a battlefield environment(!) or a DTN implementation that runs > stock market type time critical applications the delay could mean > significant/annoying losses? Well, I am not sure I'd run stock market over DTN :-) But opportunities come and go quickly, particularly with lots of attenuating stuff (people, infrastructure, etc.) around you or when driving. I guess the key is when you decide to do autoconf. If you imply using autoconf from using ad-hoc mode and assume DHCP if you are in infrastructure mode, this may be just fine (and seems quite reasonable). This at least saves the time to wait for a DHCP server that never shows up. I haven't done the math on RFC3927 yet but this would give you an idea. My hunch is that one would waste precious time here -- but starting with IPv4 autoconfig and then using the TCP convergence layer seems like a good start. > I agree that if nodes ran IPv6 and had fixed IPs then the cost of > acquiring IP would go, though neighbor discovery and negotiation would > of course sill remain. I'm inclined to believe without actually knowing > that the IP acquiring and neighbor discovery times do tend to overlap > in autoconf? I know I'm just stretching the point here. > >>>> Well, and maybe discovering >>>> whether you want to use ad-hoc or infrastructure mode... >>>> >>> Thats sounds trivial to do, but useful for sure. >> >> >> I was thinking about dynamically switching back and forth >> depending on your observed surroundings. > > > Thats an interesting question I think, perhaps a potential starting > point for Steve to think of his project. > >> Which may require >> some lower layer interaction. > > Like signal strength per packet measurements? Did you actually mean > interaction, or measurement? I meant interacting with the lower layer to determine which results the most recent scanning cycle has revealed and which networks/contacts might hence be available. This would give you the basis to decide which AP to attach to or which ad-hoc SSID to use. You can then add measurement on top (to determine when connectivity is fading), but I'd consider this a second step. Joerg Received: from fb3.its.utexas.edu (fb3.its.utexas.edu [128.83.126.204]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l22Lp4Y27833 for ; Fri, 2 Mar 2007 13:51:04 -0800 Received: from fb3.its.utexas.edu (localhost.localdomain [127.0.0.1]) by fb3.its.utexas.edu (8.12.11.20060308/8.12.11/cc-webmail.mc-1.13) with ESMTP id l22Lp4g9023071 for ; Fri, 2 Mar 2007 15:51:04 -0600 Received: (from www@localhost) by fb3.its.utexas.edu (8.12.11.20060308/8.12.11/Submit) id l22Lp3jB023069 for dtn-interest@mailman.dtnrg.org; Fri, 2 Mar 2007 15:51:03 -0600 Received: from mercury.ece.utexas.edu (mercury.ece.utexas.edu [146.6.101.9]) by webmailapp3.cc.utexas.edu (IMP) with HTTP for ; Fri, 02 Mar 2007 15:51:03 -0600 Message-ID: <1172872263.45e89c47da1cd@webmailapp3.cc.utexas.edu> Date: Fri, 02 Mar 2007 15:51:03 -0600 From: vrbaba@mail.utexas.edu To: dtn-interest@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-Originating-IP: 146.6.101.9 Subject: [dtn-interest] Support for DTN in mobile ad hoc networks Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi, I am interested in performance of DTN like mobile ad hoc networks. I was wondering if there are any current simulation environments that I can use to run some mobility scenarios within the next two months? Do you know of anyone who has developed protocols for Delay tolerant mobile ad hoc networks and done sucessful simulations using ns2, omnet++, or others? Ideally, I would like to know those protocols, and try to duplicate their results to verify a working environment, and possibly make some modifications of my own to the routing algorithm. Any help is appreciated. Thanks Varun Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l21JuNY13726 for ; Thu, 1 Mar 2007 11:56:23 -0800 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l21JuLUf008639; Thu, 1 Mar 2007 14:56:22 -0500 (EST) Received: from [18.251.5.35] (TANG-THIRTY-FIVE.MIT.EDU [18.251.5.35]) (authenticated bits=0) (User authenticated as dpsmiles@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l21JuKB1003936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Mar 2007 14:56:21 -0500 (EST) In-Reply-To: <45E72BE6.4030508@netlab.hut.fi> References: <1172767797.45e7043586cbb@mail-www.oit.umass.edu> <200703011731.RAA21937@cisco.com> <45E72191.3050104@netlab.hut.fi> <376BD19D-68A7-470C-9F7E-1B8895FFDFCE@MIT.EDU> <45E72BE6.4030508@netlab.hut.fi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Lloyd Wood , stg@student.umass.edu, dtn-interest@mailman.dtnrg.org Content-Transfer-Encoding: 7bit From: Durga Prasad Pandey Subject: Re: [dtn-interest] DTN2 ConvergenceLayers Date: Thu, 1 Mar 2007 14:56:25 -0500 To: Joerg Ott X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Mar 1, 2007, at 2:39 PM, Joerg Ott wrote: >>> Except for the autoconfiguration in ad-hoc mode (since we do not >>> have IPv6 support yet, I believe). >> I didn't know autoconf works only with IPv6 support. Am I reading >> you right? I actually looked up the IETF page for autoconf and it >> looks like the WG has been sleepy for a while, though I had >> thought autoconf has been implemented in different systems. > > Sure, you have autoconf on 169.254/16 but this takes time as nodes > have > pick and then defend addresses -- which may cost precious seconds if > you are in a rush. I am wondering what the actual delay could be numerically. Given a wireless(802.11) environment implies that the distance between nodes is not much really - at this point it usually is less than 100 metres. So the delay could probably be a few seconds and usually tolerable, but maybe in a battlefield environment(!) or a DTN implementation that runs stock market type time critical applications the delay could mean significant/annoying losses? I agree that if nodes ran IPv6 and had fixed IPs then the cost of acquiring IP would go, though neighbor discovery and negotiation would of course sill remain. I'm inclined to believe without actually knowing that the IP acquiring and neighbor discovery times do tend to overlap in autoconf? I know I'm just stretching the point here. > >>> Well, and maybe discovering >>> whether you want to use ad-hoc or infrastructure mode... >>> >> Thats sounds trivial to do, but useful for sure. > > I was thinking about dynamically switching back and forth > depending on your observed surroundings. Thats an interesting question I think, perhaps a potential starting point for Steve to think of his project. > Which may require > some lower layer interaction. Like signal strength per packet measurements? Did you actually mean interaction, or measurement? > > Joerg Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l21JgVY13618 for ; Thu, 1 Mar 2007 11:42:31 -0800 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id A1BBC4FEFD; Thu, 1 Mar 2007 21:42:29 +0200 (EET) Message-ID: <45E72BE6.4030508@netlab.hut.fi> Date: Thu, 01 Mar 2007 21:39:18 +0200 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Durga Prasad Pandey CC: Joerg Ott , Lloyd Wood , stg@student.umass.edu, dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] DTN2 ConvergenceLayers References: <1172767797.45e7043586cbb@mail-www.oit.umass.edu> <200703011731.RAA21937@cisco.com> <45E72191.3050104@netlab.hut.fi> <376BD19D-68A7-470C-9F7E-1B8895FFDFCE@MIT.EDU> In-Reply-To: <376BD19D-68A7-470C-9F7E-1B8895FFDFCE@MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: >> Except for the autoconfiguration in ad-hoc mode (since we do not >> have IPv6 support yet, I believe). > > I didn't know autoconf works only with IPv6 support. Am I reading you > right? I actually looked up the IETF page for autoconf and it looks > like the WG has been sleepy for a while, though I had thought autoconf > has been implemented in different systems. Sure, you have autoconf on 169.254/16 but this takes time as nodes have pick and then defend addresses -- which may cost precious seconds if you are in a rush. >> Well, and maybe discovering >> whether you want to use ad-hoc or infrastructure mode... >> > > Thats sounds trivial to do, but useful for sure. I was thinking about dynamically switching back and forth depending on your observed surroundings. Which may require some lower layer interaction. Joerg Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l21JdCY13553 for ; Thu, 1 Mar 2007 11:39:12 -0800 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l21Jd8Ge024305; Thu, 1 Mar 2007 14:39:10 -0500 (EST) Received: from [18.251.5.35] (TANG-THIRTY-FIVE.MIT.EDU [18.251.5.35]) (authenticated bits=0) (User authenticated as dpsmiles@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l21Jd4Yb025807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Mar 2007 14:39:05 -0500 (EST) In-Reply-To: <45E72191.3050104@netlab.hut.fi> References: <1172767797.45e7043586cbb@mail-www.oit.umass.edu> <200703011731.RAA21937@cisco.com> <45E72191.3050104@netlab.hut.fi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <376BD19D-68A7-470C-9F7E-1B8895FFDFCE@MIT.EDU> Cc: Lloyd Wood , stg@student.umass.edu, dtn-interest@mailman.dtnrg.org Content-Transfer-Encoding: 7bit From: Durga Prasad Pandey Subject: Re: [dtn-interest] DTN2 ConvergenceLayers Date: Thu, 1 Mar 2007 14:39:10 -0500 To: Joerg Ott X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: On Mar 1, 2007, at 1:55 PM, Joerg Ott wrote: > Except for the autoconfiguration in ad-hoc mode (since we do not > have IPv6 support yet, I believe). I didn't know autoconf works only with IPv6 support. Am I reading you right? I actually looked up the IETF page for autoconf and it looks like the WG has been sleepy for a while, though I had thought autoconf has been implemented in different systems. > Well, and maybe discovering > whether you want to use ad-hoc or infrastructure mode... > Thats sounds trivial to do, but useful for sure. > Joerg > > >>> Hi, >>> >>> I'm a student at UMASS doing some work with DTNs and planning on >>> writing a >>> 802.11 Convergence Layer. >> Well, IP is quite popular over 802.11. >> And DTN runs over IP. >> Job done. >> L. >>> I have been looking through the node discovery code >>> and the convergence layer interface itself. Besides some parsing >>> for the >>> dtn.conf file and these two places is there anywhere else I might >>> need to add >>> something to create my CL? >>> >>> Thanks, >>> Steve >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@mailman.dtnrg.org >> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l21IwQY13271 for ; Thu, 1 Mar 2007 10:58:26 -0800 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id B6D244FEFD; Thu, 1 Mar 2007 20:58:24 +0200 (EET) Message-ID: <45E72191.3050104@netlab.hut.fi> Date: Thu, 01 Mar 2007 20:55:13 +0200 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lloyd Wood CC: stg@student.umass.edu, dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] DTN2 ConvergenceLayers References: <1172767797.45e7043586cbb@mail-www.oit.umass.edu> <200703011731.RAA21937@cisco.com> In-Reply-To: <200703011731.RAA21937@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Except for the autoconfiguration in ad-hoc mode (since we do not have IPv6 support yet, I believe). Well, and maybe discovering whether you want to use ad-hoc or infrastructure mode... Joerg >>Hi, >> >> I'm a student at UMASS doing some work with DTNs and planning on writing a >>802.11 Convergence Layer. > > > Well, IP is quite popular over 802.11. > > And DTN runs over IP. > > Job done. > > L. > > > >>I have been looking through the node discovery code >>and the convergence layer interface itself. Besides some parsing for the >>dtn.conf file and these two places is there anywhere else I might need to add >>something to create my CL? >> >>Thanks, >>Steve > > > > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest > Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l21HVoY12676 for ; Thu, 1 Mar 2007 09:31:50 -0800 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Mar 2007 18:31:45 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l21HVgEB005716; Thu, 1 Mar 2007 18:31:42 +0100 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 l21HVdC8029277; Thu, 1 Mar 2007 18:31:41 +0100 (MET) Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4580.cisco.com [10.61.81.227]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA21937; Thu, 1 Mar 2007 17:31:33 GMT Message-Id: <200703011731.RAA21937@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Mar 2007 17:31:01 +0000 To: stg@student.umass.edu From: Lloyd Wood Subject: Re: [dtn-interest] DTN2 ConvergenceLayers Cc: dtn-interest@mailman.dtnrg.org In-Reply-To: <1172767797.45e7043586cbb@mail-www.oit.umass.edu> References: <1172767797.45e7043586cbb@mail-www.oit.umass.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: At Thursday 01/03/2007 11:49 -0500, stg@student.umass.edu wrote: >Hi, > > I'm a student at UMASS doing some work with DTNs and planning on writing a >802.11 Convergence Layer. Well, IP is quite popular over 802.11. And DTN runs over IP. Job done. L. > I have been looking through the node discovery code >and the convergence layer interface itself. Besides some parsing for the >dtn.conf file and these two places is there anywhere else I might need to add >something to create my CL? > >Thanks, >Steve Received: from race2.oit.umass.edu (race2.oit.umass.edu [128.119.101.38]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l21Go4Y12342 for ; Thu, 1 Mar 2007 08:50:04 -0800 Received: from mail-www-1.oit.umass.edu (mail-www-1.oit.umass.edu [128.119.2.109]) by race2.oit.umass.edu (8.13.7/8.13.7) with ESMTP id l21Gnw4j022944 for ; Thu, 1 Mar 2007 11:49:58 -0500 Received: (from apache@localhost) by mail-www-1.oit.umass.edu (8.13.7/8.13.7/Submit) id l21GnvSD017516 for dtn-interest@mailman.dtnrg.org; Thu, 1 Mar 2007 11:49:57 -0500 Received: from c-71-232-103-122.hsd1.ma.comcast.net (c-71-232-103-122.hsd1.ma.comcast.net [71.232.103.122]) by mail-www.oit.umass.edu (IMP) with HTTP for ; Thu, 01 Mar 2007 11:49:57 -0500 Message-ID: <1172767797.45e7043586cbb@mail-www.oit.umass.edu> Date: Thu, 01 Mar 2007 11:49:57 -0500 From: stg@student.umass.edu To: dtn-interest@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-Originating-IP: 71.232.103.122 X-Originating-Host: mail-www-1.oit.umass.edu X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Subject: [dtn-interest] DTN2 ConvergenceLayers Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: Hi, I'm a student at UMASS doing some work with DTNs and planning on writing a 802.11 Convergence Layer. I have been looking through the node discovery code and the convergence layer interface itself. Besides some parsing for the dtn.conf file and these two places is there anywhere else I might need to add something to create my CL? Thanks, Steve Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l21DkvY11163 for ; Thu, 1 Mar 2007 05:46:57 -0800 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id B5CB34FF09 for ; Thu, 1 Mar 2007 15:46:54 +0200 (EET) Message-ID: <45E6D88F.7050305@netlab.hut.fi> Date: Thu, 01 Mar 2007 15:43:43 +0200 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DTN Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [dtn-interest] WoWMoM 2007 -- Final Call for Demos Sender: dtn-interest-admin@mailman.dtnrg.org Errors-To: dtn-interest-admin@mailman.dtnrg.org X-BeenThere: dtn-interest@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: Delay Tolerant Networking Interest List List-Post: List-Help: List-Subscribe: , List-Archive: WoWMoM 2007 -- Call for Demos ============================= http://www.tml.hut.fi/IEEE-wowmom/demo.html Deadline: 6 March 2007 (EXTENDED) The demo track of IEEE WoWMoM 2007 solicits demonstrations in the world of wireless, mobile, and multimedia communications. We are looking for demonstrations of recent or ongoing research work that will showcase the research and inspire discussion and interaction with the attendees at WoWMoM 2007. We invite participation from both academia and industry demonstrating novel research results. Demonstrations will be presented in a designated demonstration slot in the conference program. The number of demos presented will be kept low in order to allow the full attention of the conference participants. WoWMoM 2007 will have a "Best Demo Award" based upon both the technical contribution and the demonstrator "showcase". Topics of interest include, but are not limited to: * System prototypes and experiences * QoS for voice and video in wireless networks * IP-based wireless multimedia applications and systems * Multimedia multicasting and broadcasting * Handoff and mobility management * Seamless internetworking and self-organization * Network management and control * Context-aware wireless multimedia applications * Location mechanism and services * Content management and distribution * Multimedia applications and systems in vehicular, mesh, and ad-hoc networks Demo proposals shall be short papers of no more than 3 pages (IEEE conference template, font size no less than 10pt) which will be reviewed by the Program Committee. The proposals should introduce the background, describe the key contributions of the author(s), and state what the demonstrator will show. A one-page appendix shall provide a comprehensive description of the demonstration and list all the technical requirements such as equipment (to be brought by the presenters) and other resources (such as # WLAN channels, Internet access, etc.), and also include a description of the demo presentation, e.g., are visitors involved, is a prototype presented that can be used by visitors, etc. The short papers of the accepted demo proposals will be included as a conference supplement, published by IEEE. It serves to inform the audience of the details behind the demo, and as a permanent record of the demo. Both the short paper and appendix must be submitted as a single PDF document by 28 February 2007. Important Dates: Submission deadline: 6 March 2007 (EXTENDED) Acceptance Notification: 20 March 2007 Camera ready deadline: 15 April 2007 Conference date: 18-21 June 2007 Paper submission will be handled through EDAS: http://www.edas.info/newPaper.php?c=5262 Jörg Ott and James Scott IEEE WoWMoM 2007 demo chairs