Subject: Re: [dtn-interest] When is the next meeting with IETF?
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 31 May 2010 12:32:19 +0100
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

That's timely. I was going to send out a mail today
in any case, asking whether folks want to meet in
Maastricht or not. Please send a mail to Kevin and I
this week saying if you think we should ask for a
session there. If you're one of the "usual suspects"
but won't be able to make Maastricht, that'd be
useful to know as well.

If you would like a speaking slot if we do meet in
Maastricht, please also let us know the topic and
roughly how long a slot you'd like.

I'll summarise back to the list at the end of the
week and we can decide then.

Thanks,
Stephen.

On 05/31/2010 09:49 AM, 오승훈 wrote:
> Hi all, 
> 
> Could anyone tell me when the next DTNRG (status/summary)meeting is going
> to be held concurrent with IETF?
> 
> Thanks in advance
> 
> Best Regards,
> Seung Hun Oh
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: =?ks_c_5601-1987?B?v8C9wsjG?= <[email-masked]>
To: <[email-masked]>
Date: Mon, 31 May 2010 17:49:03 +0900
Organization: ETRI HRC
Subject: [dtn-interest]  When is the next meeting with IETF?
Reply-To: [email-masked]

Hi all, 

Could anyone tell me when the next DTNRG (status/summary)meeting is going
to be held concurrent with IETF?

Thanks in advance

Best Regards,
Seung Hun Oh

From: Peter Lovell <[email-masked]>
To: Ashwin narasimhamurthy <[email-masked]>, [email-masked], Peter Lovell <[email-masked]>
Date: Fri, 28 May 2010 16:26:00 -0400
Subject: Re: [dtn-interest] improving reliability in DTN

On Tue, May 25, 2010, Ashwin narasimhamurthy <[email-masked]> wrote:

>Hi all,My question is about reliability in DTN, when nodes have short or
>unpredictable lifetime and without using return receipt.�
>I understand that after a node accepts custody transfer for a bundle, if
>the node gets destroyed before it transfers the bundle to next hop, the
>bundle is lost. (This risk is higher when nodes��may have to store the
>bundle for a longer period of time ,due to �non availability/disruption
>in the network)
>I am working on the following to improve reliability :
>After a node has accepted custody transfer , the node may request one or
>more adjacent nodes to store a copy of the bundle until told to be
>discarded. After the node�successfully forwards the bundle to next hop,
>it may request��the adjacent nodes to discard the bundle. Thus if the
>node is destroyed before it forwards the bundle to the next hop, the
>adjacent nodes will not receive a discard message. Hence, if possible
>(network availability and so on),
> the adjacent nodes may forward the bundle to its next hop with some
>probability (so as to reduce duplicates).�I understand that this is
>subject to various conditions such as congestion, availability of
>suitable adjacent nodes and so on.
>I request you all to freely comment about the idea. I would be happy to
>receive the expert guidance of other DTN�enthusiasts�before woking on
>this idea further.

Hi Ashwin,

there are certainly a number of situations in dtn where awkward failures
may occur and the designers have done a good job, I think, of balancing
capabilities and complexity.

The current design does indeed have a single custodian for a bundle at a
particular time. The custody-transfer-success indication goes to the old
custodian to confirm that the new one has accepted custody, and
optionally to the report-to address, typically the bundle-source. 

It is tempting to make a simple change and change the report-to address
to be the prior-old-custodian. Very tempting but impossible,
unfortunately, as that address is immutable.

So I would suggest that you consider a new extension block for this
purpose - let's call it the custody-transfer-block - which is understood
by certain nodes. It contains a number specifying how many transfers are
to be tracked, and a list with up to that many EIDs. A custodian
forwarding a bundle may add its own EID at the front of the list and
trims the list at the end to contain no more entries than the transfer
count. If the bundle is accepted for custody by the next-hop, it sends a
transfer message (format TBD) to each EID in the list indicating that
the bundle continues to make progress.

Nodes may choose to accept custody, or not. So the next-hop might accept
custody and send the transfer messages and the rfc5050-standard message.
Or it might not accept custody but still act as a relay, handing off to
other nodes that might in turn accept custody. So from the custody
standpoint, these relays are invisible ( a similar situation applies
with bundle security protocol).

You will note that I'm suggesting an alternative to your "adjacent
nodes" idea. There may be particular network topologies where "adjacent
nodes" works well but I prefer "chain of custodians". That's because we
already have a better control scenario with them, as they are already
participants in the custody-transfer mechanism. They already have a copy
of the bundle so there's less overhead. They might choose to be a
custodian but not an extended-custodian (with the new extension block).
Easily done - they handle the rfc5050 custodial signals but do not
massage the custody-transfer-block to add their EID.

I hope these suggestions help you with your consideration.

Cheers.....Peter

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 27 May 2010 09:09:52 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Glenn Research Center DTNbone update

There have been some updates to the NASA Glenn Research Center DTNbone and supporting web interface to improve usability thanks to Dennis Iannicca.

See:
http://grc-dtnbone.no-ip.org/

To see the MIBs and some packet log information for any node, just click on a node 
(you may want to open it in a separate tab or window).

The link characteristics and schedule are in the table.

The graphic refreshes every 15 seconds.

Currently, if any node gets hung up or goes down, a script in the background will detect that and restart the node.

As always, suggestions for improvement are welcomed and encouraged.

Enjoy,

--Will

From: "Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 26 May 2010 14:24:19 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] dtn-interest Digest, Vol 32, Issue 7

Ashwin narasimhamurthy asks:

>I am working on the following to improve reliability :
...
>I request you all to freely comment about the idea. I would be 
>happy to receive the expert guidance of other DTN enthusiasts 
>before woking on this idea further.

Since you are requesting comment...

Your description reads as if you are proposing that DTN include BitTorrent.  

If so, I think it should be distinct from DTN...

Regards,
Bob Ray

Advanced Avionics and Processor Systems
Jacobs/ESTS
Marshall Space Flight Center

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Ashwin narasimhamurthy <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 26 May 2010 07:45:01 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] improving reliability in DTN

--_000_3A5AA67A8B120B48825BFFCF54438561948E243897NDJSSCC03ndcn_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

First, why would a DTN node have a short lifetime?  If it did, it probably =
would not accept custody transfer.

One can argue everything that is made to last some reasonably long time per=
iod has an unpredictable lifetime.

IMHO, this is an area that is best left for long into the future.  DTN has =
far more pressing problems such as naming, scaling, routing and discovery. =
 I suggest working those first.  After all, without discovery and routing, =
how do you know who your adjacent nodes are and what they are capable and w=
illing to do?

Other comments in line.

--Will
From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Ashwin narasimhamurthy
Sent: Wednesday, May 26, 2010 1:04 AM
To: [email-masked]
Subject: [dtn-interest] improving reliability in DTN

Hi all,
My question is about reliability in DTN, when nodes have short or unpredict=
able lifetime and without using return receipt.

I understand that after a node accepts custody transfer for a bundle, if th=
e node gets destroyed before it transfers the bundle to next hop, the bundl=
e is lost.

=D8  Why would a node get destroyed?  What do you mean by getting destroyed=
?

(This risk is higher when nodes  may have to store the bundle for a longer =
period of time ,due to  non availability/disruption in the network)

=D8  It is DTN, disruption and disconnection should be assumed.  Otherwise,=
 why use a store and forward technology?  Just forward.

I am working on the following to improve reliability :

After a node has accepted custody transfer , the node may request one or mo=
re adjacent nodes to store a copy of the bundle until told to be discarded.=
 After the node successfully forwards the bundle to next hop, it may reques=
t  the adjacent nodes to discard the bundle. Thus if the node is destroyed =
before it forwards the bundle to the next hop, the adjacent nodes will not =
receive a discard message. Hence, if possible (network availability and so =
on), the adjacent nodes may forward the bundle to its next hop with some pr=
obability (so as to reduce duplicates). I understand that this is subject t=
o various conditions such as congestion, availability of suitable adjacent =
nodes and so on.

I request you all to freely comment about the idea. I would be happy to rec=
eive the expert guidance of other DTN enthusiasts before woking on this ide=
a further.

--_000_3A5AA67A8B120B48825BFFCF54438561948E243897NDJSSCC03ndcn_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:291637273;
	mso-list-type:hybrid;
	mso-list-template-ids:-1825411424 67698699 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0D8;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l1
	{mso-list-id:760375844;
	mso-list-type:hybrid;
	mso-list-template-ids:1422398876 67698699 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0D8;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>First, why would a DTN node have a short lifetime?=A0 If it =
did,
it probably would not accept custody transfer.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>One can argue everything that is made to last some reasonabl=
y
long time period has an unpredictable lifetime.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>IMHO, this is an area that is best left for long into the
future.=A0 DTN has far more pressing problems such as naming, scaling, rout=
ing
and discovery.=A0 I suggest working those first.=A0 After all, without disc=
overy
and routing, how do you know who your adjacent nodes are and what they are
capable and willing to do?<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Other comments in line.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>--Will<o:p></o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> dtn-interest-=
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Ashwin
narasimhamurthy<br>
<b>Sent:</b> Wednesday, May 26, 2010 1:04 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [dtn-interest] improving reliability in DTN<o:p></o:p></spa=
n></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<table class=3DMsoNormalTable border=3D0 cellspacing=3D0 cellpadding=3D0>
 <tr>
  <td valign=3Dtop style=3D'padding:0in 0in 0in 0in'>
  <div id=3Dyiv1938660001>
  <table class=3DMsoNormalTable border=3D0 cellspacing=3D0 cellpadding=3D0>
   <tr>
    <td style=3D'padding:0in 0in 0in 0in'>
    <p class=3DMsoNormal>Hi all,<o:p></o:p></p>
    <div>
    <p class=3DMsoNormal>My question is about reliability in DTN, when node=
s have
    short or unpredictable lifetime and without using return receipt.&nbsp;=
<o:p></o:p></p>
    </div>
    <div>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    </div>
    <div>
    <p class=3DMsoNormal>I understand that after a node accepts custody tra=
nsfer
    for a bundle, if the node gets destroyed before it transfers the bundle=
 to
    next hop, the bundle is lost. <span style=3D'color:#1F497D'><o:p></o:p>=
</span></p>
    <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 lev=
el1 lfo2'><![if !supportLists]><span
    style=3D'font-size:11.0pt;font-family:Wingdings;color:#1F497D'><span
    style=3D'mso-list:Ignore'>=D8<span style=3D'font:7.0pt "Times New Roman=
"'>&nbsp; </span></span></span><![endif]><span
    style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4=
97D'>Why
    would a node get destroyed?=A0 What do you mean by getting destroyed?=
=A0 <o:p></o:p></span></p>
    <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calib=
ri","sans-serif";
    color:#1F497D'><o:p>&nbsp;</o:p></span></p>
    <p class=3DMsoNormal>(This risk is higher when nodes&nbsp;&nbsp;may hav=
e to
    store the bundle for a longer period of time ,due to &nbsp;non
    availability/disruption in the network)<o:p></o:p></p>
    <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calib=
ri","sans-serif";
    color:#1F497D'><o:p>&nbsp;</o:p></span></p>
    <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 lev=
el1 lfo1'><![if !supportLists]><span
    style=3D'font-size:11.0pt;font-family:Wingdings;color:#1F497D'><span
    style=3D'mso-list:Ignore'>=D8<span style=3D'font:7.0pt "Times New Roman=
"'>&nbsp; </span></span></span><![endif]><span
    style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4=
97D'>It
    is DTN, disruption and disconnection should be assumed.=A0 Otherwise, w=
hy use
    a store and forward technology?=A0 Just forward.<o:p></o:p></span></p>
    </div>
    <div>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    </div>
    <div>
    <p class=3DMsoNormal>I am working on the following to improve reliabili=
ty :<o:p></o:p></p>
    </div>
    <div>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    </div>
    <div>
    <p class=3DMsoNormal>After a node has accepted custody transfer , the n=
ode
    may request one or more adjacent nodes to store a copy of the bundle un=
til
    told to be discarded. After the node&nbsp;successfully forwards the bun=
dle
    to next hop, it may request&nbsp;&nbsp;the adjacent nodes to discard th=
e
    bundle. Thus if the node is destroyed before it forwards the bundle to =
the
    next hop, the adjacent nodes will not receive a discard message. Hence,=
 if
    possible (network availability and so on), the adjacent nodes may forwa=
rd
    the bundle to its next hop with some probability (so as to reduce
    duplicates).&nbsp;I understand that this is subject to various conditio=
ns
    such as congestion, availability of suitable adjacent nodes and so on.<=
o:p></o:p></p>
    </div>
    <div>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    </div>
    <div>
    <p class=3DMsoNormal>I request you all to freely comment about the idea=
. I
    would be happy to receive the expert guidance of other
    DTN&nbsp;enthusiasts&nbsp;before woking on this idea further.<o:p></o:p=
></p>
    </div>
    <div>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    </div>
    </td>
   </tr>
  </table>
 </table>
 </div>
 </td>
</tr>
</table>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Calibri",=
"sans-serif"'><o:p>&nbsp;</o:p></span></p>

</div>

</div>

</body>

</html>

--_000_3A5AA67A8B120B48825BFFCF54438561948E243897NDJSSCC03ndcn_--

Date: Tue, 25 May 2010 22:03:54 -0700 (PDT)
From: Ashwin narasimhamurthy <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] improving reliability in DTN

--0-2029668808-1274850234=:71736
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,My question is about reliability in DTN, when nodes have short or un=
predictable lifetime and without using return receipt.=A0
I understand that after a node accepts custody transfer for a bundle, if th=
e node gets destroyed before it transfers the bundle to next hop, the bundl=
e is lost. (This risk is higher when nodes=A0=A0may have to store the bundl=
e for a longer period of time ,due to =A0non availability/disruption in the=
 network)
I am working on the following to improve reliability :
After a node has accepted custody transfer , the node may request one or mo=
re adjacent nodes to store a copy of the bundle until told to be discarded.=
 After the node=A0successfully forwards the bundle to next hop, it may requ=
est=A0=A0the adjacent nodes to discard the bundle. Thus if the node is dest=
royed before it forwards the bundle to the next hop, the adjacent nodes wil=
l not receive a discard message. Hence, if possible (network availability a=
nd so on),=0A the adjacent nodes may forward the bundle to its next hop wit=
h some probability (so as to reduce duplicates).=A0I understand that this i=
s subject to various conditions such as congestion, availability of suitabl=
e adjacent nodes and so on.
I request you all to freely comment about the idea. I would be happy to rec=
eive the expert guidance of other DTN=A0enthusiasts=A0before woking on this=
 idea further.

=0A=0A=0A      
--0-2029668808-1274850234=:71736
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><div id=3D"yiv1938660001"><table cellspacing=
=3D"0" cellpadding=3D"0" border=3D"0" id=3D"bodyDrftID" class=3D""><tbody><=
tr><td id=3D"drftMsgContent" style=3D"font:inherit;">Hi all,<div>My questio=
n is about reliability in <span>DTN</span>, when nodes have short or unpred=
ictable lifetime and without using return receipt.&nbsp;</div><div><br></di=
v><div>I understand that after a node accepts custody transfer for a bundle=
, if the node gets destroyed before it transfers the bundle to next hop, th=
e bundle is lost. (This risk is higher when nodes&nbsp;&nbsp;may have to st=
ore the bundle for a longer period of time ,due to &nbsp;non availability/d=
isruption in the network)</div><div><br></div><div>I am working on the foll=
owing to improve reliability :</div><div><br></div><div>After a node has ac=
cepted custody transfer , the node may request one or more adjacent nodes t=
o store a copy of
 the bundle until told to be discarded. After the node&nbsp;successfully fo=
rwards the bundle to next hop, it may request&nbsp;&nbsp;the adjacent nodes=
 to discard the bundle. Thus if the node is destroyed before it forwards th=
e bundle to the next hop, the adjacent nodes will not receive a discard mes=
sage. Hence, if possible (network availability and so on),=0A the adjacent =
nodes may forward the bundle to its next hop with some probability (so as t=
o reduce duplicates).&nbsp;I understand that this is subject to various con=
ditions such as congestion, availability of suitable adjacent nodes and so =
on.</div><div><br></div><div>I request you all to freely comment about the =
idea. I would be happy to receive the expert guidance of other DTN&nbsp;ent=
husiasts&nbsp;before woking on this idea further.</div><div><br></div><div>=
<br></div></td></tr></tbody></table></div></td></tr></table><br>=0A=0A     =
 
--0-2029668808-1274850234=:71736--

Date: Mon, 24 May 2010 00:33:13 -0400
From: Brenton Walker <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Pan Hui <[email-masked]>, Brenton Walker <[email-masked]>
Subject: [dtn-interest] CHANTS 2010 - Deadlines extended

Apologies if you receive multiple copies of this message.

It was requested that we extend the abstract registration deadline for
CHANTS 2010, so we have re-opened abstract registration and extended
paper submission deadlines by a week.  The new deadlines are below, and
the original CFP is attached.

Thank you,
Brenton Walker

Abstract Registration: 28 May 2010
Submission Deadline:   4  June 2010
Demo Submission:       18 June 2010

   =========================================================================
                             CALL FOR PAPERS
                   Fifth Workshop on Challenged Networks (CHANTS 2010)
Co-located with MobiCom 2010, 24 September 2010, Chicago, Illinois, USA
                     http://dtnbone.umiacs.umd.edu/chants2010
   =========================================================================

Challenged networks comprise those situations where communication is
desired, but traditional internet protocol architectures fail to provide
it effectively.  Such networks may be characterized by a heterogeneous
mix of nodes, nodal churn, and widely varying network conditions.
Common examples of challenged networks include high delay environments
such as inter-planetary networks, limited power environments such as
sensor and wildlife monitoring networks, and communication in settings
that lack infrastructure such as rural and remote areas, and military
battlefields.  Challenged networks may also be found in everyday
settings, when access to traditional infrastructure is restricted,
expensive, overly complex, or rapidly changing.  The goal of the
challenged network engineer is to design and implement systems for
effective and efficient communication in this diverse range of conditions.

The workshop solicits papers and demos relating to the following topics:
 * Architecture, design, implementation, and evaluation of communication
   systems for challenged networks
 * Analysis and characterization of challenged networks and protocols
 * Case studies involving challenged network solutions in various stages
   of development or use
 * Delay/disruption-tolerant networking (DTNs)
 * Applications in challenged networks
 * Configuration, management, and monitoring of challenged networks
 * Security concerns and solutions in challenged networks
 * Test and simulation tools for evaluating challenged network systems
 * Applications of challenged networking techniques to communication in
   daily life

Selected papers will be forward-looking, will describe their
relationship to existing work, and will have implications for ongoing or
future research.  We aim to accept approximately 12 papers, and to have
a highly interactive workshop.  Demos have been an integral part of
CHANTS, and we aim to accept up to ten demos. Paper authors who can also
run a demo of their work are encouraged to do so.  In exceptional cases
where live demos are not practical, poster or video presentations are
acceptable.

Submission Instructions:
------------------------
Submitted papers must be no more than 8 pages long, and should adhere to
the standard ACM conference proceedings format
http://www.acm.org/sigs/publications/proceedings-templates.

Paper submissions will be handled via EDAS http://edas.info/N8985

Demo abstracts (to be published as part of the proceedings) shall be at
most 3 pages plus a one page description of the precise setup and
requirements.

Demo proposals should be emailed to Earl Oliver by 18 June.
NOTE: Demo submitters should expect to receive an acknowledgment of
their submission from Earl.

Important Dates:
----------------
Abstract Registration: 28 May 2010  (was 21 May)
Submission Deadline:   4  June 2010 (was 28 May)
Demo Submission:       18 June 2010
Acceptance Notification:	1  July 2010
Camera Ready Due:	15 July 2010

Co-chairs:
----------
Pan Hui
Deutsche Telekom Laboratories
Pan.Hui_at_telekom.de

Brenton Walker
Lab for Telecommunications Sciences
brenton_at_ltsnet.net

Demo Chair:
-----------
Earl Oliver
University of Waterloo
eaoliver_at_uwaterloo.ca

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 20 May 2010 07:40:49 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] GRC DTNbone Always ON Virtual Network

Ohio University also has their ION Always ON DTN Network up.  The information exists on the DTNbone wiki at the bottom of the Ohio University section.  A new link was added at the top of the DTNbone section to make the information easier to find.

http://www.dtnrg.org/wiki/DtnBone/ou-dtnbone

Ohio University used ION and had contact graph routing and LTP on many of the links.

--Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Ivancic,
>William D. (GRC-RHN0)
>Sent: Wednesday, May 19, 2010 4:44 PM
>To: [email-masked]
>Subject: [dtn-interest] GRC DTNbone Always ON Virtual Network
>
>GRC personnel have implemented a virtual DTN network that is ALWAYS ON
>24/7 and includes multi-hop and multi-path and network management.  The
>details are on the DTNRG wiki
>
>http://www.dtnrg.org/wiki/DtnBone/grc-dtnbone
>
>
>This is a tool we hope others will use.  We would greatly appreciate
>feedback.  The contact information is on the wiki.
>
>If something does not appear to be working, please let us know.
>Sometimes one of the DTN instances crashes or a daemon stops.  We are
>learning as we go.
>
>The DTN-2 network management utility uses a daemon that updates a list
>of cache files.  If that isn't running the network management script
>will not update the web pages.  We are also going to look into including
>the DTLSR routing table in the output. Currently, only  the static table
>object is output (which, in our case, is not used and empty).
>
>Also, we are thinking about implementing some kind of bundle history on
>a node so one could see the ultimate disposition of a bundle as it
>travels through the network.  This information may already be available
>in the network management (nm_status) output and may just need to be
>parsed into the CGI output.
>
>Enjoy!
>
>Feedback is welcome and encouraged.
>
>
>-- Will
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 19 May 2010 15:44:20 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] GRC DTNbone Always ON Virtual Network

GRC personnel have implemented a virtual DTN network that is ALWAYS ON 24/7 and includes multi-hop and multi-path and network management.  The details are on the DTNRG wiki

http://www.dtnrg.org/wiki/DtnBone/grc-dtnbone

This is a tool we hope others will use.  We would greatly appreciate feedback.  The contact information is on the wiki.

If something does not appear to be working, please let us know.  Sometimes one of the DTN instances crashes or a daemon stops.  We are learning as we go.

The DTN-2 network management utility uses a daemon that updates a list of cache files.  If that isn't running the network management script will not update the web pages.  We are also going to look into including the DTLSR routing table in the output. Currently, only  the static table object is output (which, in our case, is not used and empty).  

Also, we are thinking about implementing some kind of bundle history on a node so one could see the ultimate disposition of a bundle as it travels through the network.  This information may already be available in the network management (nm_status) output and may just need to be parsed into the CGI output.  

Enjoy!

Feedback is welcome and encouraged.

-- Will

Date: Tue, 18 May 2010 08:58:01 +0200
From: aviana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] =?windows-1252?q?IEEE_MASS=9210_Workshops_Announce?= =?windows-1252?q?ment_=26_CFPs=2E?=

[We apologize in advance if you receive multiple copies of this message]
----------------------------------------------------------------------- 

              		 IEEE MASS 2010 Workshops
                    https://mass2010.soe.ucsc.edu/node/4

              November 8-12, 2010 - San Francisco, CA, USA
----------------------------------------------------------------------- 

The following workshops will be held in conjunction with the IEEE
MASS�10 conference, which will be held in the San Francisco bay area on
November 8-12, 2010:

� The Third Workshop on Mobile Entity Localization and Tracking (MELT)
(http://meltworks.org)

� The Second Workshop on SCEnarios for Network Evaluation Studies
(SCENES) (http://scenes.cs.bonn.edu)

� The Sixth Workshop on Wireless and Sensor Network Security (WSNS)
(http://www.cs.wcupa.edu/%7Ezjiang/wsns10.htm)

� The Fourth Workshop on Enabling Technologies and Standards for
Wireless Mesh Networking (MESHTECH) (http://www.ing.unipi.it/meshtech10)

� The First BioSense Workshop: Networking and Environmental Sensing meet 
Epidemiology and Biology (http://www.cl.cam.ac.uk/%7Eixyl2/biosense10/)

� The Second International Workshop on Intelligent Vehicular Networks
(InVeNet) (http://www.site.uottawa.ca/%7Exuli/InVeNET2010/)

All these workshops are currently accepting submissions. Click on each
link to get the workshop specific information regarding submission
requirements and deadlines.

Please consider submitting your work to one of these workshops.

Workshop registration will grant access to the main conference as well, 
so workshops are a great opportunity to attend IEEE MASS too and spend 
one week in beautiful California.

Looking forward to seeing you this Fall in San Francisco,

Cedric Westphal & Christine Pepin
IEEE MASS�10 Workshop Chairs.

Date: Mon, 17 May 2010 22:53:07 +0100
From: Elwyn Davies <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] updated IDs

Thanks Susan.

Those look fine to me.

Regards,
Elwyn

Symington, Susan F. wrote:
>
> Elwyn,
>
>  
>
> As requested, I just submitted updated versions of the Previous Hop 
> Insertion Block and the Metadata Extension Block I-Ds, both of which 
> now contain a reference to the DTN IANA Registries I-D and IANA 
> considerations text allocating appropriate registry codepoints.
>
>  
>
> -Susan
>
> A new version of I-D, 
> draft-irtf-dtnrg-bundle-previous-hop-block-12.txt has been 
> successfully submitted by Susan Symington and posted to the IETF 
> repository.
>
>  
>
> Filename:     draft-irtf-dtnrg-bundle-previous-hop-block
>
> Revision:     12
>
> Title:        Delay-Tolerant Networking Previous Hop Insertion Block
>
> Creation_date:       2010-05-17
>
> WG ID:        Independent Submission
>
> Number_of_pages: 12
>
> A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-08.txt 
> has been successfully submitted by Susan Symington and posted to the 
> IETF repository.
>
>  
>
> Filename:     draft-irtf-dtnrg-bundle-metadata-block
>
> Revision:     08
>
> Title:        Delay-Tolerant Networking Metadata Extension Block
>
> Creation_date:       2010-05-17
>
> WG ID:        Independent Submission
>
> Number_of_pages: 13
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>

From: "Symington, Susan F." <[email-masked]>
To: Elwyn Davies <[email-masked]>
Date: Mon, 17 May 2010 14:33:45 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] updated IDs

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC04C38F3883IMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Elwyn,

As requested, I just submitted updated versions of the Previous Hop Inserti=
on Block and the Metadata Extension Block I-Ds, both of which now contain a=
 reference to the DTN IANA Registries I-D and IANA considerations text allo=
cating appropriate registry codepoints.

-Susan

A new version of I-D, draft-irtf-dtnrg-bundle-previous-hop-block-12.txt has=
 been successfully submitted by Susan Symington and posted to the IETF repo=
sitory.

Filename:     draft-irtf-dtnrg-bundle-previous-hop-block

Revision:     12

Title:        Delay-Tolerant Networking Previous Hop Insertion Block

Creation_date:       2010-05-17

WG ID:        Independent Submission

Number_of_pages: 12

A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-08.txt has bee=
n successfully submitted by Susan Symington and posted to the IETF reposito=
ry.

Filename:     draft-irtf-dtnrg-bundle-metadata-block

Revision:     08

Title:        Delay-Tolerant Networking Metadata Extension Block

Creation_date:       2010-05-17

WG ID:        Independent Submission

Number_of_pages: 13

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC04C38F3883IMCMBX2MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<div style=3D'mso-element:para-border-div;border:none;border-bottom:solid w=
indowtext 1.0pt;
padding:0in 0in 1.0pt 0in'>

<p class=3DMsoNormal style=3D'border:none;padding:0in'><span style=3D'font-=
size:14.0pt'>Elwyn,<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'border:none;padding:0in'><span style=3D'font-=
size:14.0pt'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'border:none;padding:0in'><span style=3D'font-=
size:14.0pt'>As
requested, I just submitted updated versions of the Previous Hop Insertion
Block and the Metadata Extension Block I-Ds, both of which now contain a
reference to the DTN IANA Registries I-D and IANA considerations text alloc=
ating
appropriate registry codepoints.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'border:none;padding:0in'><span style=3D'font-=
size:14.0pt'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'border:none;padding:0in'><span style=3D'font-=
size:14.0pt'>-Susan<o:p></o:p></span></p>

</div>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>A new version of I-=
D,
draft-irtf-dtnrg-bundle-previous-hop-block-12.txt has been successfully
submitted by Susan Symington and posted to the IETF repository.<o:p></o:p><=
/span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'><o:p>&nbsp;</o:p></=
span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>Filename:&nbsp;&nbs=
p;&nbsp;&nbsp;=20
draft-irtf-dtnrg-bundle-previous-hop-block<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>Revision:&nbsp;&nbs=
p;&nbsp;&nbsp;=20
12<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>Title:&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Delay-Tolerant Networking Previous Hop Insertion Block<o:p></o:p></span></p=
>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>Creation_date:&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
2010-05-17<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>WG ID:&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Independent Submission<o:p></o:p></span></p>

<div style=3D'mso-element:para-border-div;border:none;border-bottom:solid w=
indowtext 1.0pt;
padding:0in 0in 1.0pt 0in'>

<p class=3DMsoPlainText style=3D'border:none;padding:0in'><span style=3D'fo=
nt-size:
9.0pt'>Number_of_pages: 12<o:p></o:p></span></p>

</div>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>A new version of I-=
D,
draft-irtf-dtnrg-bundle-metadata-block-08.txt has been successfully submitt=
ed
by Susan Symington and posted to the IETF repository.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'><o:p>&nbsp;</o:p></=
span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>Filename:&nbsp;&nbs=
p;&nbsp;&nbsp;=20
draft-irtf-dtnrg-bundle-metadata-block<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>Revision:&nbsp;&nbs=
p;&nbsp;&nbsp;=20
08<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>Title:&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Delay-Tolerant Networking Metadata Extension Block<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>Creation_date:&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
2010-05-17<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>WG ID:&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Independent Submission<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:9.0pt'>Number_of_pages: 13=
<o:p></o:p></span></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:14.0pt'><o:p>&nbsp;</o:p></sp=
an></p>

<p class=3DMsoNormal><span style=3D'font-size:14.0pt'><o:p>&nbsp;</o:p></sp=
an></p>

<p class=3DMsoNormal><span style=3D'font-size:14.0pt'><o:p>&nbsp;</o:p></sp=
an></p>

</div>

</body>

</html>

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC04C38F3883IMCMBX2MITREO_--

From: "Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 17 May 2010 12:26:55 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] minutes/notes from last IETF -- if you have not yet shared

Stephen Farrell stephen.farrell at cs.tcd.ie 

>Lloyd,
>
>Thanks. Its good to have folks who just want to help out.
>
>I note that your exaggerated complaint is late this time
>as well :-)
>
>Stephen.

I have an interest in seeing this work progress.  But, this circular firing squad advances nothing.

If help is needed, I volunteer.  

I have a bit of experience with the IETF (was co-chair of the ADSLMIB working group for a few years and have the scars to prove it).  I grant you that writing SNMP MIBs is not the same as protocol development.  But, in terms of the IETF publication process, they require much of the same ... attentions.

Regards,
Bob Ray

Robert E. Ray, Jr., Ph.D.
Advanced Avionics and Processor Systems
Jacobs/ESTS
Marshall Space Flight Center
EV43, Bldg. 4487, Rm B183
(256) 544-0604 (W)

"For the good you do is never lost.  
Not even in dreams."
Pedro Calderon de la Barca

Date: Thu, 13 May 2010 10:29:04 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] minutes/notes from last IETF -- if you have not yet	shared

Lloyd,

Thanks. Its good to have folks who just want to help out.

I note that your exaggerated complaint is late this time
as well :-)

Stephen.

On 05/13/2010 08:08 AM, [email-masked] wrote:
> http://www.ietf.org/meeting/cutoff-dates-2010.html
> 
> the cutoff date for submitting minutes was the 23rd of April 2010.
> 
> the cutoff date for *correcting* minutes was the 12th of May 2010.
> 
> https://datatracker.ietf.org/meeting/77/materials.html
> the IETF 77 proceedings have now gone final.
> 
> http://www.ietf.org/proceedings/77/
> DTNRG is not listed.
> 
> Once again, the DTNRG chairs have missed proceeding deadlines. This was most serious for the IETF 73 DTN meet, which weren't even published in proceedings, relegating presentations on bundle testing in space to an unpublished copy at:
> http://www.ietf.org/old/2009/proceedings/08nov/agenda/DTNRG.html
> (remove .ppt from filenames to bring up conversion - links are broken.)
> and DTNRG is not visible in:
> http://www.ietf.org/proceedings/73/
> despite meeting
> 
> Minutes have not been produced for multiple DTNRG meetings at IETFs, proceedings are lost, deadlines are missed... it's arguably all now history, as this group seems dormant and activity around the bundle protocol appears pretty much dead (to show otherwise we'd need minutes of meetings...), but we should learn from history. If not the first time, perhaps the second or third or fourth time would be nice.
> 
> Aaron, IRTF procedural matters and seemingly trivial yet actually important things like minutes and getting presentations into proceedings should be handled much better than they have been.
>  
> On 13 May 2010, at 02:06, Kevin Fall wrote:
> 
>>
>> Hi.  If you have minutes/notes from the last IETF that you haven't shared, we would like to get 'em so we can augment the IETF 77 proceedings..  Please send.
>>
>> thanks,
>> - Kevin
> 
> Lloyd Wood
> [email-masked]
> http://sat-net.com/L.Wood
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Thu, 13 May 2010 08:08:38 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] minutes/notes from last IETF -- if you have not yet	shared

http://www.ietf.org/meeting/cutoff-dates-2010.html

the cutoff date for submitting minutes was the 23rd of April 2010.

the cutoff date for *correcting* minutes was the 12th of May 2010.

https://datatracker.ietf.org/meeting/77/materials.html
the IETF 77 proceedings have now gone final.

http://www.ietf.org/proceedings/77/
DTNRG is not listed.

Once again, the DTNRG chairs have missed proceeding deadlines. This was most serious for the IETF 73 DTN meet, which weren't even published in proceedings, relegating presentations on bundle testing in space to an unpublished copy at:
http://www.ietf.org/old/2009/proceedings/08nov/agenda/DTNRG.html
(remove .ppt from filenames to bring up conversion - links are broken.)
and DTNRG is not visible in:
http://www.ietf.org/proceedings/73/
despite meeting

Minutes have not been produced for multiple DTNRG meetings at IETFs, proceedings are lost, deadlines are missed... it's arguably all now history, as this group seems dormant and activity around the bundle protocol appears pretty much dead (to show otherwise we'd need minutes of meetings...), but we should learn from history. If not the first time, perhaps the second or third or fourth time would be nice.

Aaron, IRTF procedural matters and seemingly trivial yet actually important things like minutes and getting presentations into proceedings should be handled much better than they have been.
 
On 13 May 2010, at 02:06, Kevin Fall wrote:

> 
> Hi.  If you have minutes/notes from the last IETF that you haven't shared, we would like to get 'em so we can augment the IETF 77 proceedings..  Please send.
> 
> thanks,
> - Kevin

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

From: Kevin Fall <[email-masked]>
Date: Wed, 12 May 2010 18:06:59 -0700
To: [email-masked]
Subject: [dtn-interest] minutes/notes from last IETF -- if you have not yet shared

Hi.  If you have minutes/notes from the last IETF that you haven't shared, we would like to get 'em so we can augment the IETF 77 proceedings..  Please send.

thanks,
- Kevin

From: <[email-masked]>
To: <[email-masked]>
Date: Sun, 2 May 2010 09:18:50 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked]
Subject: [dtn-interest] interesting article on clock timing and synchronization

http://queue.acm.org/detail.cfm?id=1773943
Principles of Robust Timing over the Internet 
Julien Ridoux, Darryl Veitch,  April 21, 2010

I liked the "when in doubt, just drift" section: "Nothing bad will happen unless the algorithm chooses to make it happen."

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

From: "Rigano, Chris" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sat, 1 May 2010 15:01:58 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] unsubscribe

--_000_9D2DBBF6C7F44347ABB40E047351A14804A4A6267CIMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

*********************************************************
Christopher P. Rigano (CISSP)
The MITRE Corporation / Office of Naval Research (ONR)
Lead Communications Engineer
[email-masked]<BLOCKED::blocked::mailto:[email-masked]> / chris.rigan=
[email-masked]<BLOCKED::blocked::mailto:[email-masked]>
ONR 703.696.5942 Cell 703-677-2067 MITRE 703.983.7889

--_000_9D2DBBF6C7F44347ABB40E047351A14804A4A6267CIMCMBX2MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>*********************************************************<br>
Christopher P. Rigano (CISSP)<br>
The MITRE Corporation / Office of Naval Research (ONR)<br>
Lead Communications Engineer<br>
<a href=3D"BLOCKED::blocked::mailto:[email-masked]"><span style=3D'color=
:blue'>[email-masked]</span></a><span
style=3D'color:blue'>&nbsp;/ <a
href=3D"BLOCKED::blocked::mailto:[email-masked]"><span style=3D'color=
:blue'>[email-masked]</span></a></span><span
style=3D'color:black'>&nbsp;</span><br>
ONR 703.696.5942 Cell </span>703-677-2067 <span style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'>MITRE 703.983.7889 </span><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_9D2DBBF6C7F44347ABB40E047351A14804A4A6267CIMCMBX2MITREO_--