Subject: Re: [dtn-interest] Belated Minneapolis meeting notes
From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN interest <[email-masked]>, Lloyd Wood <[email-masked]>
Date: Tue, 24 Feb 2009 16:13:32 +0000
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

Since these draft minutes were sent through as doc and pdf,
they are not archived on the dtnrg mailing list webarchive,
which strips non-text attachments.

And, thanks to missing submission deadlines, they're not
archived in the official IETF proceedings. (The presentations
are missing too: http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html
isn't linked to from anywhere in the official proceedings,
and I have to wonder about its longevity.)

Sending the final minutes to the list as text, so that they're
at least available in the list webarchive, would be a very good
idea.

L.

On 16 Feb 2009, at 14:01, Stephen Farrell wrote:

>
> Hi All,
>
> Due to a bit of a lost-file problem between Kevin and I,
> I've only now gotten together the meeting notes from last
> November. But here they are in any case. I guess just mail
> the list if there're any corrections.
>
> Thanks to Elwyn for providing raw notes (he did that in
> a timely fashion, the delay is the chairs' fault;-)
>
> Stephen.
>
> PS: I'll follow up separately wrt "last calls" and
> logistics for next month.
>
> <Meeting notes.doc><Meeting notes.pdf><mime-attachment.txt>

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

To: [email-masked]
From: Craig Partridge <[email-masked]>
Date: Mon, 23 Feb 2009 14:41:24 -0500
Sender: [email-masked]
Subject: [dtn-interest] Van Jacobson interview on content networks
Reply-To: Craig Partridge <[email-masked]>

Hi folks:

ACM Queue has just published an interview with Van about content networks.
I'm biased, as I had the fun of being the guy asking questions, but I think
many people on this list will find it of interest.

    http://mags.acm.org/queue/200901/?pg=3D8

Thanks!

Craig

Date: Mon, 23 Feb 2009 17:55:54 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] March 19-20 Logistics/Agenda

Hi All,

I've finally gotten around to posting logistics and agenda. [1]

Mail changes/additions/suggestions to Kevin and I, or the list,
as appropriate.

Regards,
Stephen.

[1] http://down.dsg.cs.tcd.ie/dtnrg-at-google/

Date: Fri, 20 Feb 2009 23:33:09 +0000
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN Naming (and addressing)

Right - already planned for actually. But maybe we should
take two slots for this - a hunk of the 1st day, then
send some folks off to write up and revisit on the 2nd
day. Aim being to come out of the meeting with something
concrete?

S.

Kevin Fall wrote:
> yes, I believe this makes sense.
> 
> - K
> 
> 
> On Feb 20, 2009, at Feb 2010:54 AMPST, Ivancic, William D. (GRC-RHN0)
> wrote:
> 
>> Kevin and Stephen,
>>
>> Since we have two days scheduled for DTNRG March 19 and 20 at Google,
>> perhaps we can take some significant time to discuss DTN Naming and
>> addressing.
>>
>> Internally NASA is looking at naming and addressing for space-base
>> DTNs.  BBN has a simplified naming scheme for testing DTN over radio
>> manets.
>>
>> Naming and Addressing is a difficult topic to get right.  DTN is
>> pretty close to a clean slate and perhaps we have to opportunity to
>> get it right.  Also, with DTNRG close to IETF, there may be an
>> opportunity to get some input for those who would like to try and get
>> it right and from those who know they got it wrong.
>>
>> Will
>>
> 

From: Kevin Fall <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 20 Feb 2009 15:13:12 -0800
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN Naming (and addressing)

yes, I believe this makes sense.

- K

On Feb 20, 2009, at Feb 2010:54 AMPST, Ivancic, William D. (GRC-RHN0)  
wrote:

> Kevin and Stephen,
>
> Since we have two days scheduled for DTNRG March 19 and 20 at  
> Google, perhaps we can take some significant time to discuss DTN  
> Naming and addressing.
>
> Internally NASA is looking at naming and addressing for space-base  
> DTNs.  BBN has a simplified naming scheme for testing DTN over radio  
> manets.
>
> Naming and Addressing is a difficult topic to get right.  DTN is  
> pretty close to a clean slate and perhaps we have to opportunity to  
> get it right.  Also, with DTNRG close to IETF, there may be an  
> opportunity to get some input for those who would like to try and  
> get it right and from those who know they got it wrong.
>
> Will
>

Date: Fri, 20 Feb 2009 15:53:17 -0600
From: Matt Bradbury <[email-masked]>
To: avri doria <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN Naming (and addressing)

Can anyone sum up the current addressing schemes being used/thought about?

You're right on this going around in circles, it was discussed here 
years ago and nothing solidified.

-Matt

avri doria wrote:
> I think this is a great idea.  Getting this right is an important step in
> terms of having our various implementations and deployments actually talk
> to each other.
>
> I know our project has been going around in circles on this for years now.
>
> a.
>
>
> On Fri, 20 Feb 2009, Ivancic, William D. (GRC-RHN0) wrote:
>
>   
>> Kevin and Stephen,
>>
>> Since we have two days scheduled for DTNRG March 19 and 20 at Google, perhaps we can take some significant time to discuss DTN Naming and addressing.
>>
>> Internally NASA is looking at naming and addressing for space-base DTNs.  BBN has a simplified naming scheme for testing DTN over radio manets.
>>
>> Naming and Addressing is a difficult topic to get right.  DTN is pretty close to a clean slate and perhaps we have to opportunity to get it right.  Also, with DTNRG close to IETF, there may be an opportunity to get some input for those who would like to try and get it right and from those who know they got it wrong.
>>
>> Will
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>     
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

Date: Fri, 20 Feb 2009 22:08:28 +0100 (MET)
From: avri doria <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN Naming (and addressing)

I think this is a great idea.  Getting this right is an important step in
terms of having our various implementations and deployments actually talk
to each other.

I know our project has been going around in circles on this for years now.

a.

On Fri, 20 Feb 2009, Ivancic, William D. (GRC-RHN0) wrote:

> Kevin and Stephen,
>
> Since we have two days scheduled for DTNRG March 19 and 20 at Google, perhaps we can take some significant time to discuss DTN Naming and addressing.
>
> Internally NASA is looking at naming and addressing for space-base DTNs.  BBN has a simplified naming scheme for testing DTN over radio manets.
>
> Naming and Addressing is a difficult topic to get right.  DTN is pretty close to a clean slate and perhaps we have to opportunity to get it right.  Also, with DTNRG close to IETF, there may be an opportunity to get some input for those who would like to try and get it right and from those who know they got it wrong.
>
> Will
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Fri, 20 Feb 2009 15:28:15 -0500
From: David Young <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Convergence Layers

Of course, complicating things even more are convergence layers that
can exist both above and below IP.  Think of LTP implementations-
probably designed to run on RF when in space, but testing on the
terrestrial internet has been mostly (if not completely) carried out
in UDP packets.  Yet it isn't really a UDPCL, and there are other UDP
convergence layers.

The infrastructure-agnostic design of DTN is a definite plus, but I'm
sure the TCP and raw-UDP CLs will (and should) be standardized in
time.

--
David Young
Ohio University

Date: Fri, 20 Feb 2009 14:06:02 -0500
From: Marc Blanchet <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN Naming (and addressing)

- agree 100%

Marc.

Ivancic, William D. (GRC-RHN0) a écrit :
> Kevin and Stephen,
> 
> Since we have two days scheduled for DTNRG March 19 and 20 at Google, perhaps we can take some significant time to discuss DTN Naming and addressing.
> 
> Internally NASA is looking at naming and addressing for space-base DTNs.  BBN has a simplified naming scheme for testing DTN over radio manets.
> 
> Naming and Addressing is a difficult topic to get right.  DTN is pretty close to a clean slate and perhaps we have to opportunity to get it right.  Also, with DTNRG close to IETF, there may be an opportunity to get some input for those who would like to try and get it right and from those who know they got it wrong.  
> 
> Will
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Fall, Kevin" <[email-masked]>, Stephen Farrell <[email-masked]>
Date: Fri, 20 Feb 2009 12:54:26 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] DTN Naming (and addressing)

Kevin and Stephen,

Since we have two days scheduled for DTNRG March 19 and 20 at Google, perhaps we can take some significant time to discuss DTN Naming and addressing.

Internally NASA is looking at naming and addressing for space-base DTNs.  BBN has a simplified naming scheme for testing DTN over radio manets.

Naming and Addressing is a difficult topic to get right.  DTN is pretty close to a clean slate and perhaps we have to opportunity to get it right.  Also, with DTNRG close to IETF, there may be an opportunity to get some input for those who would like to try and get it right and from those who know they got it wrong.  

Will

From: "Burleigh, Scott C" <[email-masked]>
To: Stephen Farrell <[email-masked]>, Wesley Eddy <[email-masked]>
Date: Fri, 20 Feb 2009 09:02:31 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

Stephen, I agree; ready to go.  One additional nit: in the first sentence of the 5th paragraph of section 4, I think the word "that" should be removed, i.e.: "The advantage in ease of parsing the old format manifests itself in two aspects...".

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Stephen
> Farrell
> Sent: Thursday, February 19, 2009 3:56 AM
> To: Wesley Eddy
> Cc: DTN
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
> 
> 
> So I think this is ready-to-go, but nonetheless have a few comments
> (attached) that Wes can take or leave as he wishes.
> 
> The only one I'd possibly argue about is #1 - the draft does seem to be
> missing a clear statement for developers as to which text is normative
> for SDNVs, but even that I consider non-blocking.
> 
> Stephen.

From: "Parikh, Salil" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 19 Feb 2009 21:50:05 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

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

That's right.  The SBEB saves the N most recent bundles according to timest=
amp in a particular "flow" (source EID, destination EID, and SBEB extension=
 cookie), and drops (obsoletes) the rest.  The SBEB draft only considered t=
he case where a single application instance is sending bundles in a flow.  =
 The ideas in your HotNets paper [1] and Mike's thesis [2] are more general=
.

[1] http://conferences.sigcomm.org/hotnets/2007/papers/hotnets6-final50.pdf

[2] Michael Demmer, "A Delay Tolerant Networking and System Architecture fo=
r Developing Regions", University of California Berkeley, Fall 2008 --- Cha=
pter 5, "A Publish / Subscribe Session Layer for Delay Tolerant Networks".

From: Kevin Fall [mailto:[email-masked]]
Sent: Monday, February 16, 2009 11:14 PM
To: Parikh, Salil
Cc: [email-masked]
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bund=
le Extension Block

We discussed this type of thing in the 2007 HotNets paper (where it was cal=
led "obsoletes").  In principal, it makes sense.  Aside from looking at an =
API, that paper discusses that there might be different sorts of 'obsoletes=
'... some are in sequence space, some are in timestamp space, and some are =
version vectors.  A quick read through this suggests to me that it only dea=
ls with timestamps.  Is that right?

- K

On Feb 11, 2009, at Feb 114:04 PMPST, Parikh, Salil wrote:

Not that this is a new idea...

See Section 3.2.12 of http://www.ietf.org/internet-drafts/draft-ietf-usefor=
-usefor-12.txt

And: Section 6.14 of http://www.eyrie.org/~eagle/usefor/other/son-of-1036

From: [email-masked]<mailto:dtn-interest=
[email-masked]> [mailto:dtn-interest-bounces@maillis=
ts.intel-research.net] On Behalf Of Parikh, Salil
Sent: Wednesday, January 07, 2009 10:30 AM
To: [email-masked]<mailto:dtn-interest@maillists=
.intel-research.net>
Subject: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle E=
xtension Block

Hello,

We have submitted an Internet-Draft titled "Delay-Tolerant Networking Super=
seding Bundle Extension Block".  We welcome review and comment from the DTN=
RG community.

http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extensi=
on-block-00.txt

Abstract:

This document defines an optional Bundle Protocol block called the Supersed=
ing Bundle Extension Block (SBEB) for use with the Bundle Protocol in the c=
ontext of the Delay-Tolerant Networking Architecture.  Applications use thi=
s block to call for the removal of previously sent bundles that are rendere=
d obsolete by more recent bundles. Upon receiving a bundle with an SBEB, a =
node will search its bundle store (and outbound queues) for bundles that ar=
e obsoleted by other related bundles according to their source and destinat=
ion EID, and the SBEB cookie (if present), and may delete some or all of th=
em. Discarding obsolete bundles helps conserve storage space and prevents e=
xpending resources in further forwarding bundles that are no longer relevan=
t.  The bundle protocol already uses expiration times to remove bundles tha=
t are no longer useful to applications.  The SBEB is a way for applications=
 to mark bundles that a node may delete prior to their expiration times.
_______________________________________________
dtn-interest mailing list
[email-masked]<mailto:[email-masked]=
el-research.net>
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--_000_06CBA47B9C3FA7409BF459DAA035248902C82F8597IMCMBX3MITREO_
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:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/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/sharepoin=
t/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://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xm=
lns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D=
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schem=
as.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.mi=
crosoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsof=
t.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/=
package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats=
.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/off=
ice/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/=
2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpa=
ges" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/typ=
es" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/mess=
ages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibr=
ary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer=
/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:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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><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'>That&#8217;s right. &nbsp;The SBEB saves the N most recent
bundles according to timestamp in a particular &#8220;flow&#8221; (source E=
ID,
destination EID, and SBEB extension cookie), and drops (obsoletes) the rest=
. &nbsp;The
SBEB draft only considered the case where a single application instance is
sending bundles in a flow.&nbsp; &nbsp;The ideas in your HotNets paper [1] =
and
Mike&#8217;s thesis [2] are more general.<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'>[1] <a
href=3D"http://conferences.sigcomm.org/hotnets/2007/papers/hotnets6-final50=
.pdf">http://conferences.sigcomm.org/hotnets/2007/papers/hotnets6-final50.p=
df</a><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'>[2] Michael Demmer, &quot;A Delay Tolerant Networking and Sy=
stem
Architecture for Developing Regions&quot;, University of California Berkele=
y, Fall
2008 --- Chapter 5, &#8220;A Publish / Subscribe Session Layer for Delay
Tolerant Networks&#8221;.<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'><o:p>&nbsp;</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>

<div>

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

<p class=3DMsoNormal style=3D'margin-left:.5in'><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"'> Kevin Fall [mailto:[email-masked]=
u] <br>
<b>Sent:</b> Monday, February 16, 2009 11:14 PM<br>
<b>To:</b> Parikh, Salil<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [dtn-interest] I-D: Delay-Tolerant Networking Supersedi=
ng
Bundle Extension Block<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'>We discussed this type of t=
hing in
the 2007 HotNets paper (where it was called &quot;obsoletes&quot;). &nbsp;I=
n
principal, it makes sense. &nbsp;Aside from looking at an API, that paper
discusses that there might be different sorts of 'obsoletes'... some are in
sequence space, some are in timestamp space, and some are version vectors.
&nbsp;A quick read through this suggests to me that it only deals with
timestamps. &nbsp;Is that right?<o:p></o:p></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'>- K<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'>On Feb 11, 2009, at Feb 114=
:04
PMPST, Parikh, Salil wrote:<o:p></o:p></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Not that this is a new
idea...</span><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-s=
erif";
color:black'><o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>See Section 3.2.12 of<spa=
n
class=3Dapple-converted-space>&nbsp;</span><a
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-12.txt=
">http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-12.txt</a></=
span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><=
o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>And: Section 6.14 of<span
class=3Dapple-converted-space>&nbsp;</span><a
href=3D"http://www.eyrie.org/~eagle/usefor/other/son-of-1036">http://www.ey=
rie.org/~eagle/usefor/other/son-of-1036</a></span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><=
o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><b><span style=3D'font-size=
:10.0pt;
font-family:"Tahoma","sans-serif";color:black'>From:</span></b><span
class=3Dapple-converted-space><span style=3D'font-size:10.0pt;font-family:"=
Tahoma","sans-serif";
color:black'>&nbsp;</span></span><span style=3D'font-size:10.0pt;font-famil=
y:
"Tahoma","sans-serif";color:black'><a
href=3D"mailto:[email-masked]">dtn-inter=
[email-masked]</a><span
class=3Dapple-converted-space>&nbsp;</span>[<a
href=3D"mailto:[email-masked]">mailto:dt=
[email-masked]</a>]<span
class=3Dapple-converted-space>&nbsp;</span><b>On Behalf Of<span
class=3Dapple-converted-space>&nbsp;</span></b>Parikh, Salil<br>
<b>Sent:</b><span class=3Dapple-converted-space>&nbsp;</span>Wednesday, Jan=
uary
07, 2009 10:30 AM<br>
<b>To:</b><span class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">dtn-interest@mail=
lists.intel-research.net</a><br>
<b>Subject:</b><span class=3Dapple-converted-space>&nbsp;</span>[dtn-intere=
st]
I-D: Delay-Tolerant Networking Superseding Bundle Extension Block</span><sp=
an
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><=
o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'>&nbsp;<o:p></o:p></span></p=
>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'>Hello,<o:p></o:p></span></p=
>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'>&nbsp;<o:p></o:p></span></p=
>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'>We have submitted an
Internet-Draft titled &#8220;Delay-Tolerant Networking Superseding Bundle
Extension Block&#8221;.&nbsp; We welcome review and comment from the DTNRG
community.<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'>&nbsp;<o:p></o:p></span></p=
>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'><a
href=3D"http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding=
-extension-block-00.txt">http://www.ietf.org/internet-drafts/draft-parikh-b=
undle-superseding-extension-block-00.txt</a><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'>&nbsp;<o:p></o:p></span></p=
>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'>Abstract:<o:p></o:p></span>=
</p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'>&nbsp;<o:p></o:p></span></p=
>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:11=
.0pt;
font-family:"Calibri","sans-serif";color:black'>This document defines an
optional Bundle Protocol block called the Superseding Bundle Extension Bloc=
k
(SBEB) for use with the Bundle Protocol in the context of the Delay-Toleran=
t
Networking Architecture.&nbsp; Applications use this block to call for the
removal of previously sent bundles that are rendered obsolete by more recen=
t
bundles. Upon receiving a bundle with an SBEB, a node will search its bundl=
e
store (and outbound queues) for bundles that are obsoleted by other related
bundles according to their source and destination EID, and the SBEB cookie =
(if
present), and may delete some or all of them. Discarding obsolete bundles h=
elps
conserve storage space and prevents expending resources in further forwardi=
ng
bundles that are no longer relevant.&nbsp; The bundle protocol already uses
expiration times to remove bundles that are no longer useful to
applications.&nbsp; The SBEB is a way for applications to mark bundles that=
 a
node may delete prior to their expiration times.<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-size:13=
.5pt;
font-family:"Helvetica","sans-serif";color:black'>_________________________=
______________________<br>
dtn-interest mailing list<br>
<a href=3D"mailto:[email-masked]">dtn-interest@m=
aillists.intel-research.net</a><br>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><o:=
p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_06CBA47B9C3FA7409BF459DAA035248902C82F8597IMCMBX3MITREO_--

From: "Jason Redi" <[email-masked]>
To: "'Daniel Ellard'" <[email-masked]>
Date: Thu, 19 Feb 2009 09:35:05 -0500
Organization: BBN Technologies
Cc: [email-masked], 'Andrew James Jenkins' <[email-masked]>
Subject: Re: [dtn-interest] Convergence Layers
Reply-To: [email-masked]

> -----Original Message-----
> From: Daniel Ellard [mailto:[email-masked]]
> Sent: Thursday, February 19, 2009 9:27 AM
> To: [email-masked]
> Cc: 'Andrew James Jenkins'; [email-masked]
> Subject: Re: [dtn-interest] Convergence Layers
> 
> Jason Redi wrote:
> >> There might be a compelling reason why the ION TCP CL is
> >> incompatible with the DTN2 TCP CL (or vice versa--I don't
> >> know which was written first) but there's no mention of it
> >> here.  The only thing that is clear is that the router now
> >> needs to know what kind of node it's talking to before
> >> choosing the correct TCP CL, and this seems like a nuisance
> >> when constructing a MANET or a platform-agnostic ad-hoc
> >> network of any kind.
> >
> > Dan,
> > Sorry to disagree with you, but completely platform-agnostic MANETs
> are not
> > desirable.  Typically when people design platform-agnostic routing
> > protocols, they mean not using any MAC or RF information of any kind
> (no
> > ETX, SNR, etc) since those are really specific to the kind of MAC or
> RF you
> > are using.  MANETs are hard enough to make work without throwing away
> such
> > valuable information.  MANETs that entirely run on only received or
> > transmitted packets at the application really don't work very well.
> 
> I don't think we're completely disagreeing; down at the
> signal level, there are many "niches" and good reasons to
> have waveform-specific CLs.  But once you're at the IP level
> or above, I suspect that the number of niches decreases.

If I understand you are saying that BPAs that live above IP, the CLA should
be platform agnostic (just as IP is).  Yes I agree.   And if one has a BPA
that does not live above IP, but the CLA talks to a MAC or some
platform-specific kind of network, then the CLA would likely be
platform-specific.  Yes, I agree with that.   

Jason

---
Dr. Jason K. Redi
BBN Technologies                               
10 Moulton St., Cambridge, MA, 02138
[email-masked]

Date: Thu, 19 Feb 2009 09:26:44 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: [email-masked]
Cc: [email-masked], 'Andrew James Jenkins' <[email-masked]>
Subject: Re: [dtn-interest] Convergence Layers

Jason Redi wrote:
>> There might be a compelling reason why the ION TCP CL is
>> incompatible with the DTN2 TCP CL (or vice versa--I don't
>> know which was written first) but there's no mention of it
>> here.  The only thing that is clear is that the router now
>> needs to know what kind of node it's talking to before
>> choosing the correct TCP CL, and this seems like a nuisance
>> when constructing a MANET or a platform-agnostic ad-hoc
>> network of any kind.
> 
> Dan,
> Sorry to disagree with you, but completely platform-agnostic MANETs are not
> desirable.  Typically when people design platform-agnostic routing
> protocols, they mean not using any MAC or RF information of any kind (no
> ETX, SNR, etc) since those are really specific to the kind of MAC or RF you
> are using.  MANETs are hard enough to make work without throwing away such
> valuable information.  MANETs that entirely run on only received or
> transmitted packets at the application really don't work very well.

I don't think we're completely disagreeing; down at the 
signal level, there are many "niches" and good reasons to 
have waveform-specific CLs.  But once you're at the IP level 
or above, I suspect that the number of niches decreases.

-Dan

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: Daniel Ellard <[email-masked]>, Andrew James Jenkins <[email-masked]>
Date: Thu, 19 Feb 2009 08:16:39 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Convergence Layers

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Daniel Ellard
>Sent: Thursday, February 19, 2009 8:50 AM
>
>If there is a compelling reason for having two different 
>convergence layers for the same underlying protocol, then it 
>may make sense, for example, to have more than one TCP CL. 
>In this situation, the fact that they both utilize TCP is a 
>red herring.  They're different protocols.
>
>There might be a compelling reason why the ION TCP CL is 
>incompatible with the DTN2 TCP CL (or vice versa--I don't 
>know which was written first) but there's no mention of it 
>here.  The only thing that is clear is that the router now 
>needs to know what kind of node it's talking to before 
>choosing the correct TCP CL, and this seems like a nuisance 
>when constructing a MANET or a platform-agnostic ad-hoc 
>network of any kind.

In the case of the two incompatible TCP CLs, they both share
the same strengths and weaknesses of using TCP; they're just
different ways of marshalling the bits into the TCP stream.
I agree, there's no reason to maintain both.

>I think we should avoid multiple CLs that occupy the same niche.

Then the challenge is to define the niches well enough that the
solutions for each niche have near-optimality across the entire
parameter-space of that niche.

From: "Jason Redi" <[email-masked]>
To: "'Daniel Ellard'" <[email-masked]>, "'Andrew James Jenkins'" <[email-masked]>
Date: Thu, 19 Feb 2009 09:01:28 -0500
Organization: BBN Technologies
Sender: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Convergence Layers
Reply-To: [email-masked]

> There might be a compelling reason why the ION TCP CL is
> incompatible with the DTN2 TCP CL (or vice versa--I don't
> know which was written first) but there's no mention of it
> here.  The only thing that is clear is that the router now
> needs to know what kind of node it's talking to before
> choosing the correct TCP CL, and this seems like a nuisance
> when constructing a MANET or a platform-agnostic ad-hoc
> network of any kind.

Dan,
Sorry to disagree with you, but completely platform-agnostic MANETs are not
desirable.  Typically when people design platform-agnostic routing
protocols, they mean not using any MAC or RF information of any kind (no
ETX, SNR, etc) since those are really specific to the kind of MAC or RF you
are using.  MANETs are hard enough to make work without throwing away such
valuable information.  MANETs that entirely run on only received or
transmitted packets at the application really don't work very well.

Jason 

PS:  This is a religious-war that has been going on in the MANET community
for some time.

---
 Dr. Jason K. Redi
 BBN Technologies                               
 10 Moulton St., Cambridge, MA, 02138
 [email-masked]

Date: Thu, 19 Feb 2009 08:49:30 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Andrew James Jenkins <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Convergence Layers

Andrew James Jenkins wrote:
> I don't believe that the DTN architecture requires exactly one
> convergence layer for every underlying protocol.

It might not require it, but perhaps it's a good idea.

> For instance, ION (an implementation of DTN's BP, among other things)
> has an ION-specific TCP CLA that does not interoperate with DTN2's TCP
> CLA.  For my work, we've written and happily used a DTN2-interoperable
> TCP CLA side-by-side with the ION TCP CLA.  Both CLAs work at the same
> time in the same instance of ION without any problems; the way ION
> specifies forwarding plans and rules selects between the two.  One CLA
> talks to all the other ION nodes in our net, and the other talks to the
> DTN2s.  If I was in the OCMP world instead, I could hook one CLA up to
> my EDGE IP, and another up to my WiFi IP.

If there is a compelling reason for having two different 
convergence layers for the same underlying protocol, then it 
may make sense, for example, to have more than one TCP CL. 
In this situation, the fact that they both utilize TCP is a 
red herring.  They're different protocols.

There might be a compelling reason why the ION TCP CL is 
incompatible with the DTN2 TCP CL (or vice versa--I don't 
know which was written first) but there's no mention of it 
here.  The only thing that is clear is that the router now 
needs to know what kind of node it's talking to before 
choosing the correct TCP CL, and this seems like a nuisance 
when constructing a MANET or a platform-agnostic ad-hoc 
network of any kind.

I think we should avoid multiple CLs that occupy the same niche.

-Dan

Date: Thu, 19 Feb 2009 11:55:44 +0000
From: Stephen Farrell <[email-masked]>
To: Wesley Eddy <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

This is a multi-part message in MIME format.
--------------080609020407050803050004
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

So I think this is ready-to-go, but nonetheless have a few
comments (attached) that Wes can take or leave as he wishes.

The only one I'd possibly argue about is #1 - the draft
does seem to be missing a clear statement for developers as
to which text is normative for SDNVs, but even that I
consider non-blocking.

Stephen.

--------------080609020407050803050004
Content-Type: text/plain;
 name="sdnv-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="sdnv-01.txt"

SF's "last call" notes on draft-irtf-dtnrg-sdnv-01

General:

#1: I think the something like the following would be a useful addition to the
intro, just before the start of 1.1. (We already define them twice, a 3rd time
would just be careless:-) The justification for this document not being
normative, is, I hope, clear.  (When/if we revise 5050 and 5326, I can well
imagine we might separate out the SDNV definition into its own RFC, which could
essentially be an update from this, but we're not doing that now.)

   "SDNVs are defined in both the bundle protocol [RFC5050] and LTP. [RFC5326]
   (This was due to some sequencing issues in the order of document production
   in the DTNRG.) This document is intended to clarify and furhter explain
   their use, but implementers should note that the normative definition of
   SDNVs is to be found in those RFCs."

#2: I agree with the earlier comment that this is a bit wordy and would
encourage you to think about removing some of the commentary that might
generate hard-to-process comments during IRSG review. But its your call, I have
no objection to the current text. Examples: "painfully incorrect" might easily
raise someone's hackles, "particularly wise" might annoy someone who doesn't
think DTN is the best thing ever, etc.

#3, start of section 2: is "tag identifiers" correct (enough?) Maybe
add a parenthetical "(actually object identifier arc values)"? [Did 
we have that discussion before - it rings a bell;-)]

#4, last para of section 2: is it worth saying that "Protocols using
SDNVs should call out any situations where zero padding might cause
problems." Bit vague, but maybe worthwhile.

Nits:

#0, there's some IRTF boilerplate to be added; check with your shepherd before
re-submitting for IRSG review (and I can't recall right now what's needed,
something like "this is from DTNRG; mostly people liked it" and maybe some
other guff.

#1, introL s/was created/has created/

#2, 1.2 s/In proposals for the/In the/ 

#3, I've no idea if the reference to the expired BRF04 will cause
problems, but we'll see;-)

#4: Update refs to RFC 5050, 5326, 4963

--------------080609020407050803050004--

Date: Thu, 19 Feb 2009 13:13:01 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] Call for Papers: MobiArch 2009 (co-located with ACM MobiSys) -- extended deadline

                         Call for Papers

          The 4th ACM International Workshop on Mobility
       in the Evolving Internet Architecture (MobiArch 2009)
       -----------------------------------------------------

      Co-located with MobiSys, 22 June 2009, Krakow, Poland
     http://user.informatik.uni-goettingen.de/~mobiarch/2009/

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, multi-homing,
security, wireless access 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. For instance, an appropriate system that allows communicating
with a mobile host requires addressing several fundamental issues with
the Internet architecture, such as ability to locate the mobile
host/service, preserving ongoing communications upon changes of
locations, as well as efficient and secure handover management. As
another example, the emerging wireless technologies may pose additional
challenges to the Internet architecture since they introduce design
principles different from the original Internet.

MobiArch 2009 welcomes submissions, from both researchers and
practitioners, in exploration of recent advances in architectures,
protocols, and experiences with emerging technologies on various
mobility issues 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 modelling, multi-homing, security,
architectural impacts and deployment considerations. Furthermore, the
potential of usability of mobility services for connecting people and
devices in developing regions of the world into the Internet
infrastructure will be also explored.

Topics of MobiArch 2009 cover all aspects of architectural issues and
system support for mobility in the Internet, including but not limited to:

* Impacts of new wireless technologies/services, networking
   technologies, 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, routing, locator/identifier split, multi-homing
   and load sharing issues
* Security and privacy issues in mobility networks and impacts to
   Internet architecture
* Architectures and mechanisms for wireless/mobile connectivity in
   extreme environments (e.g., remote areas, developing countries)
* Performance issues with mobility in the Internet
* QoS and middlebox issues in mobility networks and impacts to Internet
   architecture
* Economic and deployment issues of mobility solutions (infrastructure
   and devices)
* Impact of social aspects on mobility architectures, mobile application
   and protocol design
* Technologies for mobile wireless access and interactions

Submissions must present original results. Selected papers will be
forward-looking, describe their relationship to existing work, and have
impact and implications for ongoing or future research.
Submitted papers must be no more than 6 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. All paper submission
will be handled via EDAS (http://edas.info/7188). Papers will be
reviewed single blind.

Important Dates:

     Submission Deadline:       6 March 2009 (extended)
     Acceptance Notification:  31 March 2009
     Camera Ready Due:         15 April 2009
     Workshop Date:            22 June 2009

TPC Chairs:

     Joerg Ott   Helsinki University of Technology (TKK)
     Kun Tan     Microsoft Research Asia

For more information, contact workshop co-chairs at 
[email-masked].

Date: Thu, 19 Feb 2009 12:00:53 +0100
From: Janico Greifenberg <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

Hi,

I have implemented SDNV handling and the draft is fine by me.

So long
Janico

Content-class: urn:content-classes:message
Date: Thu, 19 Feb 2009 06:24:05 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Convergence Layers

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9925A.A9E94EA1
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The engineering costs are prohibitive because they're per-NIC.
Porting bundle code to support every NIC and convergence layer
directly with per-NIC convergence layers doesn't scale.

If the NICs already supports IP (and TCP), and you haven't had
to pay those sunk costs, the prospective costs of creating a
per-NIC convergence layer in the hope of some engineering
optimisation is not compelling. At which point, you can
evaluate IP (which is suitable for a wide variety of
environments) and TCP (which is suitable for a smaller set)
and use one or both.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: S. Keshav [mailto:[email-masked]]
Sent: Wed 2009-02-18 22:06
To: Edwards, William L (Will)
Cc: Wood L Dr (Electronic Eng); [email-masked]; =
[email-masked]
Subject: Re: [dtn-interest] Convergence Layers
=20
TCP is universal too, and we build on *that*! I don't see why the =20
engineering costs are prohibitive.

keshav

On Feb 18, 2009, at 4:44 PM, Edwards, William L (Will) wrote:

> Great point.  I agree.
>
> Bill
>
> From: [email-masked] =
[mailto:[email-masked]=20
> ] On Behalf Of [email-masked]
> Sent: Wednesday, February 18, 2009 4:36 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [dtn-interest] Convergence Layers
>
> > Instead, it makes sense to have a convergence layer per NIC type
>
> the engineering costs are prohibitive.
>
> IP is universal, and runs over the NIC; we build on that.
>
>
>

------_=_NextPart_001_01C9925A.A9E94EA1
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Convergence Layers</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>The engineering costs are prohibitive because they're =
per-NIC.<BR>
Porting bundle code to support every NIC and convergence layer<BR>
directly with per-NIC convergence layers doesn't scale.<BR>
<BR>
If the NICs already supports IP (and TCP), and you haven't had<BR>
to pay those sunk costs, the prospective costs of creating a<BR>
per-NIC convergence layer in the hope of some engineering<BR>
optimisation is not compelling. At which point, you can<BR>
evaluate IP (which is suitable for a wide variety of<BR>
environments) and TCP (which is suitable for a smaller set)<BR>
and use one or both.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: S. Keshav [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Wed 2009-02-18 22:06<BR>
To: Edwards, William L (Will)<BR>
Cc: Wood L Dr (Electronic Eng); [email-masked]; =
[email-masked]<BR>
Subject: Re: [dtn-interest] Convergence Layers<BR>
<BR>
TCP is universal too, and we build on *that*! I don't see why =
the&nbsp;<BR>
engineering costs are prohibitive.<BR>
<BR>
keshav<BR>
<BR>
On Feb 18, 2009, at 4:44 PM, Edwards, William L (Will) wrote:<BR>
<BR>
&gt; Great point.&nbsp; I agree.<BR>
&gt;<BR>
&gt; Bill<BR>
&gt;<BR>
&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:=
[email-masked]</A><BR>
&gt; ] On Behalf Of [email-masked]<BR>
&gt; Sent: Wednesday, February 18, 2009 4:36 PM<BR>
&gt; To: [email-masked]; [email-masked]<BR>
&gt; Cc: [email-masked]<BR>
&gt; Subject: Re: [dtn-interest] Convergence Layers<BR>
&gt;<BR>
&gt; &gt; Instead, it makes sense to have a convergence layer per NIC =
type<BR>
&gt;<BR>
&gt; the engineering costs are prohibitive.<BR>
&gt;<BR>
&gt; IP is universal, and runs over the NIC; we build on that.<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9925A.A9E94EA1--

Date: Wed, 18 Feb 2009 22:20:53 -0800
From: "Scott C. Burleigh" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Contact Graph Routing

Ivancic, William D. (GRC-RHN0) wrote:
> Scott,
>
> Regarding Contact Graph Routing (CGR):  
>
> Is it fair to say that CGR could be applied to any store-and-forward network and is not limited to a DTN based on bundling?
>   
I think that's right, Will.  The specifics of the implementation depend 
on the notion of a "node number", but the basic principles of route 
computation are probably protocol-independent.
> Regarding the DINET experiments:
>
> Was CGR performed at a central source and the CGR route tables and contact times pushed out to the various forwarding nodes or were the contact times pushed out to the various forwarding nodes and the CGR routes calculated at each forwarding node?   I can see value in either approach.  For example, the centralized approach  allows one to debug at a single location which is probably quite useful for early experimentation.  
>
> This question is a result of looking at various network management requirements.
>   
The contact plan (the raw schedule of contact start/stop times and data 
rates, together with the distances [in light seconds] between the nodes) 
was distributed to all the nodes and turned into a slightly different 
contact graph -- rooted at the local node -- on each node.  Then each 
node performed routed computation locally using its own contact graph.

You're right, debugging at a central location would have been way 
easier, but the route computation has to be distributed: different 
routes might be computed for two successive bundles with the same final 
destination, due to differences in priority or TTL, so you really don't 
have routing tables.  That makes centralized route computation 
impractical, especially over long links.

Scott

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 22:16:06 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Convergence Layers

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99216.BF72A2D9
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Actually the most universal thing today in the internet
> is http over tcp and port 80.

...which is why we proposed HTTP-DTN:
http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/=
draft-wood-dtnrg-http-dtn-delivery/

to leverage all that application code that speaks HTTP.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

------_=_NextPart_001_01C99216.BF72A2D9
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Convergence Layers</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>&gt; Actually the most universal thing today in the =
internet<BR>
&gt; is http over tcp and port 80.<BR>
<BR>
...which is why we proposed HTTP-DTN:<BR>
<A =
HREF=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet=
-drafts/draft-wood-dtnrg-http-dtn-delivery/">http://info.ee.surrey.ac.uk/=
Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-de=
livery/</A><BR>
<BR>
to leverage all that application code that speaks HTTP.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C99216.BF72A2D9--

From: "Jason Redi" <[email-masked]>
To: "'S. Keshav'" <[email-masked]>, "'Edwards, William L \(Will\)'" <[email-masked]>
Date: Wed, 18 Feb 2009 17:11:06 -0500
Organization: BBN Technologies
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Convergence Layers
Reply-To: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_0619_01C991EB.E5C0A700
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Actually the most universal thing today in the internet is http over tcp and
port 80.   

From: [email-masked]
[mailto:[email-masked]] On Behalf Of S.
Keshav
Sent: Wednesday, February 18, 2009 5:07 PM
To: Edwards, William L (Will)
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [dtn-interest] Convergence Layers

TCP is universal too, and we build on *that*! I don't see why the
engineering costs are prohibitive.

keshav

On Feb 18, 2009, at 4:44 PM, Edwards, William L (Will) wrote:

Great point.  I agree.

Bill

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, February 18, 2009 4:36 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Convergence Layers

> Instead, it makes sense to have a convergence layer per NIC type

the engineering costs are prohibitive.

IP is universal, and runs over the NIC; we build on that.

 

------=_NextPart_000_0619_01C991EB.E5C0A700
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-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<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:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	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
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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 style=3D'word-wrap: =
break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Actually the most universal thing today in the internet =
is http
over tcp and port 80.&nbsp;&nbsp; <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>

<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"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf =
Of </b>S.
Keshav<br>
<b>Sent:</b> Wednesday, February 18, 2009 5:07 PM<br>
<b>To:</b> Edwards, William L (Will)<br>
<b>Cc:</b> [email-masked]; [email-masked];
[email-masked]<br>
<b>Subject:</b> Re: [dtn-interest] Convergence =
Layers<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal>TCP is universal too, and we build on *that*! I =
don't see why
the engineering costs are prohibitive.<o:p></o:p></p>

<div>

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

</div>

<div>

<p class=3DMsoNormal>keshav<o:p></o:p></p>

</div>

<div>

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

<div>

<div>

<p class=3DMsoNormal>On Feb 18, 2009, at 4:44 PM, Edwards, William L =
(Will)
wrote:<o:p></o:p></p>

</div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-family:"Verdana","sans-serif";color:black'>Great
point.&nbsp; I agree.</span><span =
style=3D'color:black'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span =
style=3D'font-family:"Verdana","sans-serif";color:black'>&nbsp;</span><sp=
an
style=3D'color:black'><o:p></o:p></span></p>

<div>

<p class=3DMsoNormal><span =
style=3D'font-family:"Verdana","sans-serif";color:black'>Bill</span><span=

style=3D'color:black'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span =
style=3D'font-family:"Verdana","sans-serif";color:black'>&nbsp;</span><sp=
an
style=3D'color:black'><o:p></o:p></span></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span
style=3D'color:black'>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</span></div>

<div>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:black'>From:</span></b><span class=3Dapple-converted-space><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>=
&nbsp;</span></span><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>=
<a
href=3D"mailto:[email-masked]">dtn-int=
[email-masked]</a>
[<a =
href=3D"mailto:[email-masked]">mailto:=
[email-masked]</a>]<span
class=3Dapple-converted-space>&nbsp;</span><b>On Behalf Of<span
class=3Dapple-converted-space>&nbsp;</span></b><a
href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b>Sent:</b><span class=3Dapple-converted-space>&nbsp;</span>Wednesday, =
February
18, 2009 4:36 PM<br>
<b>To:</b><span class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">[email-masked]</a>;<span
class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">[email-masked]</a>=
<br>
<b>Cc:</b><span class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">[email-masked]=
.org</a><br>
<b>Subject:</b><span class=3Dapple-converted-space>&nbsp;</span>Re:
[dtn-interest] Convergence Layers</span><span =
style=3D'color:black'><o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><span =
style=3D'color:black'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:10.0pt;color:black'>&gt;
Instead, it makes sense to have a convergence layer per NIC type<br>
<br>
the engineering costs are prohibitive.<br>
<br>
IP is universal, and runs over the NIC; we build on that.<br>
<br>
</span><span style=3D'color:black'><o:p></o:p></span></p>

</div>

</div>

</div>

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

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_0619_01C991EB.E5C0A700--

From: "S. Keshav" <[email-masked]>
To: "Edwards, William L (Will)" <[email-masked]>
Date: Wed, 18 Feb 2009 17:06:55 -0500
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Convergence Layers

--Apple-Mail-80--1010421800
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

TCP is universal too, and we build on *that*! I don't see why the  
engineering costs are prohibitive.

keshav

On Feb 18, 2009, at 4:44 PM, Edwards, William L (Will) wrote:

> Great point.  I agree.
>
> Bill
>
> From: [email-masked] [mailto:[email-masked] 
> ] On Behalf Of [email-masked]
> Sent: Wednesday, February 18, 2009 4:36 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [dtn-interest] Convergence Layers
>
> > Instead, it makes sense to have a convergence layer per NIC type
>
> the engineering costs are prohibitive.
>
> IP is universal, and runs over the NIC; we build on that.
>
>
>

--Apple-Mail-80--1010421800
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">TCP is universal too, and we =
build on *that*! I don't see why the engineering costs are =
prohibitive.<div><br></div><div>keshav</div><div><br><div><div>On Feb =
18, 2009, at 4:44 PM, Edwards, William L (Will) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"blue"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"3" color=3D"black" =
face=3D"Verdana"><span style=3D"font-size: 12pt; font-family: Verdana; =
color: black; ">Great point.&nbsp; I agree.</span></font></div><p =
class=3D"MsoNormal" style=3D"margin-top: 0in; margin-right: 0in; =
margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: =
'Times New Roman'; "><font size=3D"3" color=3D"black" =
face=3D"Verdana"><span style=3D"font-size: 12pt; font-family: Verdana; =
color: black; ">&nbsp;</span></font></p><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"3" color=3D"black" =
face=3D"Verdana"><span style=3D"font-size: 12pt; font-family: Verdana; =
color: black; ">Bill</span></font></div><p class=3D"MsoNormal" =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" color=3D"black" face=3D"Verdana"><span =
style=3D"font-size: 12pt; font-family: Verdana; color: black; =
">&nbsp;</span></font></p><div><div class=3D"MsoNormal" align=3D"center" =
style=3D"text-align: center; margin-top: 0in; margin-right: 0in; =
margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: =
'Times New Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; "><hr size=3D"2" width=3D"100%" align=3D"center"=
 tabindex=3D"-1"></span></font></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><b><font size=3D"2" =
face=3D"Tahoma"><span style=3D"font-size: 10pt; font-family: Tahoma; =
font-weight: bold; ">From:</span></font></b><font size=3D"2" =
face=3D"Tahoma"><span style=3D"font-size: 10pt; font-family: Tahoma; =
"><span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]">dtn-inte=
[email-masked]</a> [<a =
href=3D"mailto:[email-masked]" =
style=3D"color: blue; text-decoration: underline; =
">mailto:[email-masked]</a>]<span =
class=3D"Apple-converted-space">&nbsp;</span><b><span =
style=3D"font-weight: bold; ">On Behalf Of<span =
class=3D"Apple-converted-space">&nbsp;</span></span></b><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a><br><b><span =
style=3D"font-weight: bold; ">Sent:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Wednesday, February 18, =
2009 4:36 PM<br><b><span style=3D"font-weight: bold; =
">To:</span></b><span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a>;<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a><br><b><span =
style=3D"font-weight: bold; ">Cc:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; =
">[email-masked]</a><br><b><span style=3D"font-weight: =
bold; ">Subject:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Re: [dtn-interest] =
Convergence Layers</span></font></div></div><p class=3D"MsoNormal" =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">&nbsp;</span></font></p><p =
style=3D"margin-bottom: 12pt; margin-right: 0in; margin-left: 0in; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"2" =
face=3D"Times New Roman"><span style=3D"font-size: 10pt; ">> Instead, it =
makes sense to have a convergence layer per NIC type<br><br>the =
engineering costs are prohibitive.<br><br>IP is universal, and runs over =
the NIC; we build on =
that.<br><br><br></span></font></p></div></div></span></blockquote></div><=
br></div></body></html>=

--Apple-Mail-80--1010421800--

From: "Jason Redi" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 18 Feb 2009 16:59:56 -0500
Organization: BBN Technologies
Sender: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Convergence Layers
Reply-To: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_05F6_01C991EA.566F9DA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

It may be worthwhile to consider the MANET example.  In the IETF, MANETs are
defined to run alongside IP.   However, most (all?) military MANET networks
run below IP.  There are many reasons, but the two key reasons were to 1.
not expose the rapidly changing MANET routes to the rest of the IP routing
architecture (OSPF, etc); 2. Allow the MANET to get some information from
the link layer without IP obscuring all details.

The message is that probably the best answer of whether a CLA should be NIC
or IP-specific depends on the architecture and problem being solved. I'm not
sure that we understand all scenarios that DTNs would be involved with yet,
so this warrants extended discussion.

Jason

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, February 18, 2009 4:36 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Convergence Layers

> Instead, it makes sense to have a convergence layer per NIC type

the engineering costs are prohibitive.

IP is universal, and runs over the NIC; we build on that.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

------=_NextPart_000_05F6_01C991EA.566F9DA0
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-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
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)">
<title>RE: [dtn-interest] Convergence Layers</title>
<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: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
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It may be worthwhile to consider the MANET example.&nbsp; =
In the
IETF, MANETs are defined to run alongside IP.&nbsp;&nbsp; However, most =
(all?)
military MANET networks run below IP.&nbsp; There are many reasons, but =
the two
key reasons were to 1. not expose the rapidly changing MANET routes to =
the rest
of the IP routing architecture (OSPF, etc); 2. Allow the MANET to get =
some
information from the link layer without IP obscuring all =
details.<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'>The message is that probably the best answer of whether a =
CLA should
be NIC or IP-specific depends on the architecture and problem being =
solved. I&#8217;m
not sure that we understand all scenarios that DTNs would be involved =
with yet,
so this warrants extended discussion.<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'>Jason<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>

<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"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf =
Of </b>[email-masked]<br>
<b>Sent:</b> Wednesday, February 18, 2009 4:36 PM<br>
<b>To:</b> [email-masked]; [email-masked]<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [dtn-interest] Convergence =
Layers<o:p></o:p></span></p>

</div>

</div>

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

<p style=3D'margin-bottom:12.0pt'><span style=3D'font-size:10.0pt'>&gt; =
Instead, it
makes sense to have a convergence layer per NIC type<br>
<br>
the engineering costs are prohibitive.<br>
<br>
IP is universal, and runs over the NIC; we build on that.<br>
<br>
L.<br>
<br>
&lt;<a =
href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</a>&gt;&lt;[email-masked]&gt;</span><o:p></o=
:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_05F6_01C991EA.566F9DA0--

From: "Jason Redi" <[email-masked]>
To: "'Durst, Robert C.'" <[email-masked]>, "'Ivancic, William D. \(GRC-RHN0\)'" <[email-masked]>, <[email-masked]>
Date: Wed, 18 Feb 2009 16:53:07 -0500
Organization: BBN Technologies
Subject: Re: [dtn-interest] DTN Security related question
Reply-To: [email-masked]

The specific program that Bob is talking about here is DARPA WNaN.  The idea
there is that DTN is the "native" mode, which means to us that the BPA sits
directly above an RF MAC layer.  We have a CLA that is designed for talking
to this particular MAC (which supports multi-transceiver, multi-frequency).

In our system, the BPA sits below IP from the perspective of native IP apps.
IP apps think they just send regular packets, they go to IP, then get sent
to the BPA.  The BPA looks like an Ethernet-class device to the IP stack.
Every packet that goes over the multihop network goes through the BPA
whether it really gets stored or not.   We do an immediate decision whether
to forward and/or store or drop.  Some packets (such as VoIP) which would
not want disrupted service may just get dropped if we don't know an
immediate next hop.   This arrangement of IP over another forwarding module
is very similar to what the MANET world calls 3a or subnet routing.

As an amusing note, we can also use a UDP CLA in this architecture which
allows for IP-in-BP-in-IP packets.

This kind of an architecture might be useful to consider as well.

Jason

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Durst,
> Robert C.
> Sent: Wednesday, February 18, 2009 2:58 PM
> To: Ivancic, William D. (GRC-RHN0); [email-masked]
> Subject: Re: [dtn-interest] DTN Security related question
> 
> I know of one military implementation of DTN in which DTN *is* the
> network layer, and switches to IP-based convergence layers at a gateway
> when communicating with DTN apps on more traditional networks.  That
> implementation has the prospect of being the largest DTN deployment
> anywhere for a very long time.  My understanding is that they are
> planning to use DTN's BSP.  I don't feel like I'm at liberty to say
> more about this, but others on this list might.  I believe that there
> are ongoing conversations within the DARPA DTN program regarding
> authoring an extension to the DTN Architecture RFC (separate draft)
> that discusses use of DTN as a native network layer for these kinds of
> RF MANETs, but I don't believe that monkey has jumped onto anyone's
> back yet.
> 
> Regarding encryption of data at rest, I'm currently working on a
> project that uses DTN as a way of storing encrypted data at rest, and
> using bundle metadata, encrypted separately from the payload, to carry
> content-based tags to that data.  That's all running over IP at the
> moment, and the gain is *definitely* worth the pain.
> 
> HTH,
> Bob
> 
> |-----Original Message-----
> |From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Ivancic,
> |William D. (GRC-RHN0)
> |Sent: Wednesday, February 18, 2009 11:19 AM
> |To: [email-masked]
> |Subject: [dtn-interest] DTN Security related question
> |
> |I know the space community is running DTN over CCSDS protocols or what
> |may become CCSDS protocols (LTP).  I also know there is a convergence
> |layer for remote storage (sneaker net) as well a Bluetooth.
> |
> |Are the vast majority of DTN implementations running TCP or UDP
> |(basically IP)?
> |
> |Are communities such as the military using DTN to not only for store
> and
> |forward, but to bridge heterogeneous networks (i.e. IP to non-IP or
> |legacy-1 to legacy-2)?  For such systems, security might currently
> only
> |exist at the radio layer.  So, I can see the desire for DTN Bundle
> |Security here.
> |
> |Military networks generally require radio layer security and may have
> |bulk encryption on the wire line.  There are also requirements for
> |network-layer security for IP networks.  In addition, there are often
> |requirements to secure data-at-rest.  So, for an DTN over an IP
> network,
> |is the gain worth the pain to run bundle security?
> |
> |Regarding deep space networks where everything is scheduled and you
> know
> |to whom you are communicating. The risk of a system being compromise
> at
> |the DTN layer seems much less likely than the risk of locking yourself
> |out of the system at the DTN layer. Using a symmetric shared key
> |between different owners (United States, Japan, Russia, China) is
> |probably not wise.  However, maintaining unique keys over
> disconnected,
> |systems with planetary delays is problematic.
> |
> |
> |
> |******************************
> |William D. Ivancic
> |Phone 216-433-3494
> |Fax 216-433-8705
> |Networking Lab 216-433-2620
> |DTN Lab 216-433-2981
> |Mobile 440-503-4892
> |http://roland.grc.nasa.gov/~ivancic
> |
> |_______________________________________________
> |dtn-interest mailing list
> [email-masked]
> |http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 21:44:28 +0000
From: "Edwards, William L (Will)" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Convergence Layers

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99212.1312D92C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Great point.  I agree.

=20

Bill

=20

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, February 18, 2009 4:36 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Convergence Layers

=20

> Instead, it makes sense to have a convergence layer per NIC type

the engineering costs are prohibitive.

IP is universal, and runs over the NIC; we build on that.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

------_=_NextPart_001_01C99212.1312D92C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<title>RE: [dtn-interest] Convergence Layers</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	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";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Verdana;
	color:black;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3DVerdana><span
style=3D'font-size:12.0pt;font-family:Verdana;color:black'>Great =
point.&nbsp; I agree.</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3DVerdana><span
style=3D'font-size:12.0pt;font-family:Verdana;color:black'>&nbsp;</span><=
/font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3DVerdana><span
style=3D'font-size:12.0pt;font-family:Verdana;color:black'>Bill</span></f=
ont></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3DVerdana><span
style=3D'font-size:12.0pt;font-family:Verdana;color:black'>&nbsp;</span><=
/font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] =
[mailto:[email-masked]]
<b><span style=3D'font-weight:bold'>On Behalf Of =
</span></b>[email-masked]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, February =
18, 2009
4:36 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked];
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: =
[dtn-interest]
Convergence Layers</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p style=3D'margin-bottom:12.0pt'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; Instead, it makes sense to have a =
convergence
layer per NIC type<br>
<br>
the engineering costs are prohibitive.<br>
<br>
IP is universal, and runs over the NIC; we build on that.<br>
<br>
L.<br>
<br>
&lt;<a =
href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</a>&gt;&lt;[email-masked]&gt;</span></font><=
/p>

</div>

</body>

</html>

------_=_NextPart_001_01C99212.1312D92C--

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 21:35:36 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Convergence Layers

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99211.02933CC3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Instead, it makes sense to have a convergence layer per NIC type

the engineering costs are prohibitive.

IP is universal, and runs over the NIC; we build on that.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

------_=_NextPart_001_01C99211.02933CC3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Convergence Layers</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>&gt; Instead, it makes sense to have a convergence =
layer per NIC type<BR>
<BR>
the engineering costs are prohibitive.<BR>
<BR>
IP is universal, and runs over the NIC; we build on that.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C99211.02933CC3--

Date: Wed, 18 Feb 2009 14:06:44 -0700
From: Andrew James Jenkins <[email-masked]>
To: "S. Keshav" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Convergence Layers

I don't believe that the DTN architecture requires exactly one
convergence layer for every underlying protocol.

For instance, ION (an implementation of DTN's BP, among other things)
has an ION-specific TCP CLA that does not interoperate with DTN2's TCP
CLA.  For my work, we've written and happily used a DTN2-interoperable
TCP CLA side-by-side with the ION TCP CLA.  Both CLAs work at the same
time in the same instance of ION without any problems; the way ION
specifies forwarding plans and rules selects between the two.  One CLA
talks to all the other ION nodes in our net, and the other talks to the
DTN2s.  If I was in the OCMP world instead, I could hook one CLA up to
my EDGE IP, and another up to my WiFi IP.

I believe in this case, I'm using one TCP convergence layer per
listening TCP port, just like how OCMP uses one TCP convergence layer
per NIC type.  A different implementation of BP could have one TCP
convergence layer per NIC type or per security zone or whatever (as
RFC5050 says, "implementation-specific" :-) ).

Andrew

S. Keshav wrote:
> I have long felt that the use of protocol-specific convergence layers is
> a fundamental flaw in the DTN architecture. As a very simple example,
> TCP used hop-by-hop over bluetooth and TCP used end-to-end over
> GPRS/EDGE/3G are very different in their routing, intrinsic capacity,
> and security challenges. Why should a single 'TCP convergence layer'
> have to deal with everything TCP can do? Instead, it makes sense to have
> a convergence layer per NIC type (which is what we've done with OCMP
> [1]). This isn't perfect either (it mixes device-to-device WiFi with
> device-to-infrastructure WiFi), but it is still a lot cleaner than the
> DTN design.
> 
> keshav
> 
> [1] http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/05/ocmp.pdf
> 
> On Feb 18, 2009, at 3:15 PM, Ivancic, William D. (GRC-RHN0) wrote:
> 
>> Probably a very worth while topic to add to the DTN agenda for March
>> 19 and 20.
>>  
>>  
>> Will
>>  
>>
>> ******************************
>> William D. Ivancic
>> Phone 216-433-3494
>> Fax 216-433-8705
>> Networking Lab 216-433-2620
>> DTN Lab 216-433-2981
>> Mobile 440-503-4892
>> http://roland.grc.nasa.gov/~ivancic
>>
>>  
>>
>>     ------------------------------------------------------------------------
>>     *From:* [email-masked] [mailto:[email-masked]]
>>     *Sent:* Wednesday, February 18, 2009 3:10 PM
>>     *To:* Ivancic, William D. (GRC-RHN0);
>>     [email-masked] <mailto:[email-masked]>
>>     *Subject:* RE: [dtn-interest] Convergence Layers
>>
>>     Before we ask 'how do we manage a convergence layer' shouldn't we
>>     ask 'what is a convergence layer expected to do?' and define that?
>>
>>     L.
>>
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "S. Keshav" <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 18 Feb 2009 15:30:03 -0500
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Convergence Layers

--Apple-Mail-62--1016234044
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I have long felt that the use of protocol-specific convergence layers  
is a fundamental flaw in the DTN architecture. As a very simple  
example, TCP used hop-by-hop over bluetooth and TCP used end-to-end  
over GPRS/EDGE/3G are very different in their routing, intrinsic  
capacity, and security challenges. Why should a single 'TCP  
convergence layer' have to deal with everything TCP can do? Instead,  
it makes sense to have a convergence layer per NIC type (which is what  
we've done with OCMP [1]). This isn't perfect either (it mixes device- 
to-device WiFi with device-to-infrastructure WiFi), but it is still a  
lot cleaner than the DTN design.

keshav

[1] http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/05/ocmp.pdf

On Feb 18, 2009, at 3:15 PM, Ivancic, William D. (GRC-RHN0) wrote:

> Probably a very worth while topic to add to the DTN agenda for March  
> 19 and 20.
>
>
> Will
>
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
>
>
>
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 18, 2009 3:10 PM
> To: Ivancic, William D. (GRC-RHN0); [email-masked]
> Subject: RE: [dtn-interest] Convergence Layers
>
> Before we ask 'how do we manage a convergence layer' shouldn't we
> ask 'what is a convergence layer expected to do?' and define that?
>
> L.

--Apple-Mail-62--1016234044
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I have long felt that the use =
of protocol-specific convergence layers is a fundamental flaw in the DTN =
architecture. As a very simple example, TCP used hop-by-hop over =
bluetooth and TCP used end-to-end over GPRS/EDGE/3G are very different =
in their routing, intrinsic capacity, and security challenges. Why =
should a single 'TCP convergence layer' have to deal with everything TCP =
can do? Instead, it makes sense to have a convergence layer per NIC type =
(which is what we've done with OCMP [1]). This isn't perfect either (it =
mixes device-to-device WiFi with device-to-infrastructure WiFi), but it =
is still a lot cleaner than the DTN =
design.<div><br></div><div>keshav</div><div><br></div><div>[1]&nbsp;<a =
href=3D"http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/05/ocmp.pd=
f">http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/05/ocmp.pdf</a>=
</div><div><br><div><div>On Feb 18, 2009, at 3:15 PM, Ivancic, William =
D. (GRC-RHN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"> <div> =
<div dir=3D"ltr" align=3D"left"><span class=3D"765341420-18022009"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2">Probably a very worth while =
topic to add to the DTN agenda for March 19 and 20.</font></span></div> =
<div dir=3D"ltr" align=3D"left"><span class=3D"765341420-18022009"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div> =
<div dir=3D"ltr" align=3D"left"><span class=3D"765341420-18022009"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div> =
<div dir=3D"ltr" align=3D"left"><span class=3D"765341420-18022009"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2">Will</font></span></div> =
<div>&nbsp;</div><!-- Converted from text/plain format --><p><font =
size=3D"2">******************************<br>William D. Ivancic<br>Phone =
216-433-3494<br>Fax 216-433-8705<br>Networking Lab 216-433-2620<br>DTN =
Lab 216-433-2981<br>Mobile 440-503-4892<br><a =
href=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/~i=
vancic</a><br></font></p> <div>&nbsp;</div><br> <blockquote dir=3D"ltr" =
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">  <div class=3D"OutlookMessageHeader" =
lang=3D"en-us" dir=3D"ltr" align=3D"left">  <hr tabindex=3D"-1">  <font =
face=3D"Tahoma" size=3D"2"><b>From:</b> [email-masked]   [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>] =
<br><b>Sent:</b> Wednesday, February 18, 2009   3:10 PM<br><b>To:</b> =
Ivancic, William D. (GRC-RHN0);   <a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a><br><b>Subject:</b> RE: [dtn-interest]   Convergence =
Layers<br></font><br></div>  <div></div><!-- Converted from text/plain =
format --><p><font size=3D"2">Before we ask 'how do we manage a =
convergence layer' shouldn't   we<br>ask 'what is a convergence layer =
expected to do?' and define   =
that?<br><br>L.</font></p></blockquote></div></blockquote></div></div></bo=
dy></html>=

--Apple-Mail-62--1016234044--

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 20:22:38 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Convergence Layers

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99206.D68CF821
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Is there an agenda? Haven't seen one; I've requested one previously.

(The 'what should a convergence layer do?' question is an old one.)

L.

DTN work: http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]]
Sent: Wed 2009-02-18 20:15
To: Wood L Dr (Electronic Eng); [email-masked]
Subject: RE: [dtn-interest] Convergence Layers
=20
Probably a very worth while topic to add to the DTN agenda for March 19 =
and 20.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 18, 2009 3:10 PM
To: Ivancic, William D. (GRC-RHN0); [email-masked]
Subject: RE: [dtn-interest] Convergence Layers

Before we ask 'how do we manage a convergence layer' shouldn't we
ask 'what is a convergence layer expected to do?' and define that?

L.

DTN work: http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Ivancic, William D. (GRC-RHN0)
Sent: Wed 2009-02-18 18:55
To: [email-masked]
Subject: [dtn-interest] Convergence Layers

I am working on a document for network management.  Convergence layers =
are one item we believe requires management.  I am trying to put some =
quick text on the various convergence layers and associated references.

Is there any documented proposals for removable storage (sneaker net) or =
Bluetooth?

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

T

------_=_NextPart_001_01C99206.D68CF821
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Convergence Layers</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Is there an agenda? Haven't seen one; I've requested =
one previously.<BR>
<BR>
(The 'what should a convergence layer do?' question is an old one.)<BR>
<BR>
L.<BR>
<BR>
DTN work: <A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://www.=
ee.surrey.ac.uk/Personal/L.Wood/saratoga/</A><BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
-----Original Message-----<BR>
From: Ivancic, William D. (GRC-RHN0) [<A =
HREF=3D"mailto:[email-masked]">mailto:William.D.Ivancic@nasa.=
gov</A>]<BR>
Sent: Wed 2009-02-18 20:15<BR>
To: Wood L Dr (Electronic Eng); [email-masked]<BR>
Subject: RE: [dtn-interest] Convergence Layers<BR>
<BR>
Probably a very worth while topic to add to the DTN agenda for March 19 =
and 20.<BR>
<BR>
<BR>
Will<BR>
<BR>
<BR>
******************************<BR>
William D. Ivancic<BR>
Phone 216-433-3494<BR>
Fax 216-433-8705<BR>
Networking Lab 216-433-2620<BR>
DTN Lab 216-433-2981<BR>
Mobile 440-503-4892<BR>
<A =
HREF=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/~=
ivancic</A><BR>
<BR>
<BR>
<BR>
________________________________<BR>
From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Wednesday, February 18, 2009 3:10 PM<BR>
To: Ivancic, William D. (GRC-RHN0); [email-masked]<BR>
Subject: RE: [dtn-interest] Convergence Layers<BR>
<BR>
<BR>
Before we ask 'how do we manage a convergence layer' shouldn't we<BR>
ask 'what is a convergence layer expected to do?' and define that?<BR>
<BR>
L.<BR>
<BR>
DTN work: <A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://www.=
ee.surrey.ac.uk/Personal/L.Wood/saratoga/</A><BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Ivancic, William D. (GRC-RHN0)<BR>
Sent: Wed 2009-02-18 18:55<BR>
To: [email-masked]<BR>
Subject: [dtn-interest] Convergence Layers<BR>
<BR>
I am working on a document for network management.&nbsp; Convergence =
layers are one item we believe requires management.&nbsp; I am trying to =
put some quick text on the various convergence layers and associated =
references.<BR>
<BR>
Is there any documented proposals for removable storage (sneaker net) or =
Bluetooth?<BR>
<BR>
Will<BR>
<BR>
<BR>
******************************<BR>
William D. Ivancic<BR>
Phone 216-433-3494<BR>
Fax 216-433-8705<BR>
Networking Lab 216-433-2620<BR>
DTN Lab 216-433-2981<BR>
Mobile 440-503-4892<BR>
<A =
HREF=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/~=
ivancic</A><BR>
<BR>
_______________________________________________<BR>
dtn-interest mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
<BR>
<BR>
T</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C99206.D68CF821--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 18 Feb 2009 14:15:14 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Convergence Layers

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

Probably a very worth while topic to add to the DTN agenda for March 19 and=
 20.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 18, 2009 3:10 PM
To: Ivancic, William D. (GRC-RHN0); [email-masked]
Subject: RE: [dtn-interest] Convergence Layers

Before we ask 'how do we manage a convergence layer' shouldn't we
ask 'what is a convergence layer expected to do?' and define that?

L.

DTN work: http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of Ivanci=
c, William D. (GRC-RHN0)
Sent: Wed 2009-02-18 18:55
To: [email-masked]
Subject: [dtn-interest] Convergence Layers

I am working on a document for network management.  Convergence layers are =
one item we believe requires management.  I am trying to put some quick tex=
t on the various convergence layers and associated references.

Is there any documented proposals for removable storage (sneaker net) or Bl=
uetooth?

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [dtn-interest] Convergence Layers</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16809" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D765341420-18022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Probably a very worth while topic to add to the DT=
N agenda=20
for March 19 and 20.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D765341420-18022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D765341420-18022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D765341420-18022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Will</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV><!-- Converted from text/plain format -->
<P><FONT size=3D2>******************************<BR>William D. Ivancic<BR>P=
hone=20
216-433-3494<BR>Fax 216-433-8705<BR>Networking Lab 216-433-2620<BR>DTN Lab=
=20
216-433-2981<BR>Mobile 440-503-4892<BR><A=20
href=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/~iv=
ancic</A><BR></FONT></P>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli=
d; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, February 18, 200=
9=20
  3:10 PM<BR><B>To:</B> Ivancic, William D. (GRC-RHN0);=20
  [email-masked]<BR><B>Subject:</B> RE: [dtn-interest]=20
  Convergence Layers<BR></FONT><BR></DIV>
  <DIV></DIV><!-- Converted from text/plain format -->
  <P><FONT size=3D2>Before we ask 'how do we manage a convergence layer' sh=
ouldn't=20
  we<BR>ask 'what is a convergence layer expected to do?' and define=20
  that?<BR><BR>L.<BR><BR>DTN work: <A=20
  href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://www.=
ee.surrey.ac.uk/Personal/L.Wood/saratoga/</A><BR><BR>&lt;<A=20
  href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR><BR><BR><BR>-=
----Original=20
  Message-----<BR>From: [email-masked] o=
n=20
  behalf of Ivancic, William D. (GRC-RHN0)<BR>Sent: Wed 2009-02-18 18:55<BR=
>To:=20
  [email-masked]<BR>Subject: [dtn-interest] Convergence=20
  Layers<BR><BR>I am working on a document for network management.&nbsp;=20
  Convergence layers are one item we believe requires management.&nbsp; I a=
m=20
  trying to put some quick text on the various convergence layers and assoc=
iated=20
  references.<BR><BR>Is there any documented proposals for removable storag=
e=20
  (sneaker net) or=20
  Bluetooth?<BR><BR>Will<BR><BR><BR>******************************<BR>Willi=
am D.=20
  Ivancic<BR>Phone 216-433-3494<BR>Fax 216-433-8705<BR>Networking Lab=20
  216-433-2620<BR>DTN Lab 216-433-2981<BR>Mobile 440-503-4892<BR><A=20
  href=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/~=
ivancic</A><BR><BR>_______________________________________________<BR>dtn-i=
nterest=20
  mailing list<BR>[email-masked]<BR><A=20
  href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><BR>=
<BR></FONT></P></BLOCKQUOTE></BODY></HTML>

--_000_3A5AA67A8B120B48825BFFCF544385613EC6569ENDJSSCC03ndcnas_--

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 20:10:15 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Convergence Layers

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99205.145BCFF3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Before we ask 'how do we manage a convergence layer' shouldn't we
ask 'what is a convergence layer expected to do?' and define that?

L.

DTN work: http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Ivancic, William D. (GRC-RHN0)
Sent: Wed 2009-02-18 18:55
To: [email-masked]
Subject: [dtn-interest] Convergence Layers
=20
I am working on a document for network management.  Convergence layers =
are one item we believe requires management.  I am trying to put some =
quick text on the various convergence layers and associated references.

Is there any documented proposals for removable storage (sneaker net) or =
Bluetooth?

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic=20

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------_=_NextPart_001_01C99205.145BCFF3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Convergence Layers</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Before we ask 'how do we manage a convergence layer' =
shouldn't we<BR>
ask 'what is a convergence layer expected to do?' and define that?<BR>
<BR>
L.<BR>
<BR>
DTN work: <A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://www.=
ee.surrey.ac.uk/Personal/L.Wood/saratoga/</A><BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Ivancic, William D. (GRC-RHN0)<BR>
Sent: Wed 2009-02-18 18:55<BR>
To: [email-masked]<BR>
Subject: [dtn-interest] Convergence Layers<BR>
<BR>
I am working on a document for network management.&nbsp; Convergence =
layers are one item we believe requires management.&nbsp; I am trying to =
put some quick text on the various convergence layers and associated =
references.<BR>
<BR>
Is there any documented proposals for removable storage (sneaker net) or =
Bluetooth?<BR>
<BR>
Will<BR>
<BR>
<BR>
******************************<BR>
William D. Ivancic<BR>
Phone 216-433-3494<BR>
Fax 216-433-8705<BR>
Networking Lab 216-433-2620<BR>
DTN Lab 216-433-2981<BR>
Mobile 440-503-4892<BR>
<A =
HREF=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/~=
ivancic</A><BR>
<BR>
_______________________________________________<BR>
dtn-interest mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C99205.145BCFF3--

From: "Durst, Robert C." <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 18 Feb 2009 14:57:50 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] DTN Security related question

I know of one military implementation of DTN in which DTN *is* the network layer, and switches to IP-based convergence layers at a gateway when communicating with DTN apps on more traditional networks.  That implementation has the prospect of being the largest DTN deployment anywhere for a very long time.  My understanding is that they are planning to use DTN's BSP.  I don't feel like I'm at liberty to say more about this, but others on this list might.  I believe that there are ongoing conversations within the DARPA DTN program regarding authoring an extension to the DTN Architecture RFC (separate draft) that discusses use of DTN as a native network layer for these kinds of RF MANETs, but I don't believe that monkey has jumped onto anyone's back yet.

Regarding encryption of data at rest, I'm currently working on a project that uses DTN as a way of storing encrypted data at rest, and using bundle metadata, encrypted separately from the payload, to carry content-based tags to that data.  That's all running over IP at the moment, and the gain is *definitely* worth the pain.

HTH,
Bob

|-----Original Message-----
|From: [email-masked] [mailto:dtn-
[email-masked]] On Behalf Of Ivancic,
|William D. (GRC-RHN0)
|Sent: Wednesday, February 18, 2009 11:19 AM
|To: [email-masked]
|Subject: [dtn-interest] DTN Security related question
|
|I know the space community is running DTN over CCSDS protocols or what
|may become CCSDS protocols (LTP).  I also know there is a convergence
|layer for remote storage (sneaker net) as well a Bluetooth.
|
|Are the vast majority of DTN implementations running TCP or UDP
|(basically IP)?
|
|Are communities such as the military using DTN to not only for store and
|forward, but to bridge heterogeneous networks (i.e. IP to non-IP or
|legacy-1 to legacy-2)?  For such systems, security might currently only
|exist at the radio layer.  So, I can see the desire for DTN Bundle
|Security here.
|
|Military networks generally require radio layer security and may have
|bulk encryption on the wire line.  There are also requirements for
|network-layer security for IP networks.  In addition, there are often
|requirements to secure data-at-rest.  So, for an DTN over an IP network,
|is the gain worth the pain to run bundle security?
|
|Regarding deep space networks where everything is scheduled and you know
|to whom you are communicating. The risk of a system being compromise at
|the DTN layer seems much less likely than the risk of locking yourself
|out of the system at the DTN layer. Using a symmetric shared key
|between different owners (United States, Japan, Russia, China) is
|probably not wise.  However, maintaining unique keys over disconnected,
|systems with planetary delays is problematic.
|
|
|
|******************************
|William D. Ivancic
|Phone 216-433-3494
|Fax 216-433-8705
|Networking Lab 216-433-2620
|DTN Lab 216-433-2981
|Mobile 440-503-4892
|http://roland.grc.nasa.gov/~ivancic
|
|_______________________________________________
|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, 18 Feb 2009 12:55:59 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Convergence Layers

I am working on a document for network management.  Convergence layers are one item we believe requires management.  I am trying to put some quick text on the various convergence layers and associated references.

Is there any documented proposals for removable storage (sneaker net) or Bluetooth?

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

Date: Wed, 18 Feb 2009 17:04:01 +0000
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN Security related question

Hi Will,

I guess my general answer is that YMMV.

Generally, systems make use of security at different levels, in many
web systems sometimes its easier to run over a VPN for server-server
connections, but sometimes, TLS is a better option. It often depends
on where the relevant endpoints are and who trusts whom for what.
So what you'd like to have are the options to turn on security at
various layers. For me, that alone justifies developing the bundle
security stuff, but then I'm a security-head, so I would say that
wouldn't I:-)

As you say, if your DTN traverses different CLs then the bundle
security stuff gets more useful. But I'd guess that even in a DTN
that all runs over IP, there will be cases where you'd like the
inbound bundles to be authenticated at some gateway, and I can
also envisage cases where you'd want to to combine confid. with
bundle-in-bundle encapsulation.

For space, I'd guess that there may be cases where you'd like to
have bundles authenticated in the ground segment, but as you
say, its probably not interesting for the spacecraft links.
(Though maybe lunar exploration scenarios might be different?)

Anyway, that's a bit of a meandering answer, but the question
wasn't that precise so maybe that's fair:-)

Stephen.

PS: I'd guess you'll find a lot of this was discussed before
if you go back far enough in the list archive. (Which now
makes me wonder if that's easily searchable;-)

Ivancic, William D. (GRC-RHN0) wrote:
> I know the space community is running DTN over CCSDS protocols or what may become CCSDS protocols (LTP).  I also know there is a convergence layer for remote storage (sneaker net) as well a Bluetooth.
> 
> Are the vast majority of DTN implementations running TCP or UDP (basically IP)?  
> 
> Are communities such as the military using DTN to not only for store and forward, but to bridge heterogeneous networks (i.e. IP to non-IP or legacy-1 to legacy-2)?  For such systems, security might currently only exist at the radio layer.  So, I can see the desire for DTN Bundle Security here.
> 
> Military networks generally require radio layer security and may have bulk encryption on the wire line.  There are also requirements for network-layer security for IP networks.  In addition, there are often requirements to secure data-at-rest.  So, for an DTN over an IP network, is the gain worth the pain to run bundle security?  
> 
> Regarding deep space networks where everything is scheduled and you know to whom you are communicating. The risk of a system being compromise at the DTN layer seems much less likely than the risk of locking yourself out of the system at the DTN layer. Using a symmetric shared key  between different owners (United States, Japan, Russia, China) is probably not wise.  However, maintaining unique keys over disconnected, systems with planetary delays is problematic.
> 
> 
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic 
> 
> _______________________________________________
> 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, 18 Feb 2009 10:18:50 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTN Security related question

I know the space community is running DTN over CCSDS protocols or what may become CCSDS protocols (LTP).  I also know there is a convergence layer for remote storage (sneaker net) as well a Bluetooth.

Are the vast majority of DTN implementations running TCP or UDP (basically IP)?  

Are communities such as the military using DTN to not only for store and forward, but to bridge heterogeneous networks (i.e. IP to non-IP or legacy-1 to legacy-2)?  For such systems, security might currently only exist at the radio layer.  So, I can see the desire for DTN Bundle Security here.

Military networks generally require radio layer security and may have bulk encryption on the wire line.  There are also requirements for network-layer security for IP networks.  In addition, there are often requirements to secure data-at-rest.  So, for an DTN over an IP network, is the gain worth the pain to run bundle security?  

Regarding deep space networks where everything is scheduled and you know to whom you are communicating. The risk of a system being compromise at the DTN layer seems much less likely than the risk of locking yourself out of the system at the DTN layer. Using a symmetric shared key  between different owners (United States, Japan, Russia, China) is probably not wise.  However, maintaining unique keys over disconnected, systems with planetary delays is problematic.

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 16:04:35 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

This is a multi-part message in MIME format.

------_=_NextPart_001_01C991E2.D921221B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Unfortunately, reliability isn't a security issue (and attempting to
treat it as such has its own problems, as we've seen.)

Calling this out solely in the *security* section as a security
issue is not sufficient, imo.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Hans Kruse
Sent: Wed 2009-02-18 15:19
To: Delay Tolerant Networking Interest List
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
=20
I am in favor of moving the document forward as-is (no additional =20
disclaimer of recommendation).  The security section appropriately =20
calls for validity checking during the decode.  Once any protocol =20
header (whether it contains SDNVs or not) contains undetected errors, =20
bad things happen.  The present security language, while aimed at =20
intentionally malformed packets, is IMHO sufficient warning.

On Feb 18, 2009, at 10:00 AM, Stephen Farrell wrote:

>
> I think its clear from previous discussions that the "highly
> recommended" phrase you suggest does not have broad support.
> (My read is that people are fine with having the option to
> add checksums, and are waiting for the spec for that to
> complete, but I only see you guys constantly saying that
> they're required.)
>
> So adding such phraseology is IMO inappropriate in this case
> since it makes an otherwise uncontroversial and useful document
> into something that's being used as part of an unrelated
> argument. That's independent or the merit, or lack of merit,
> of the argument so I reckon that entwining things like that
> is not useful.
>
> And to be clear: I'm not accusing anyone here of bad will, I
> just think there's no need and no benefit in dragging this
> argument into every single thing.
>
> Stephen.
>
> Ivancic, William D. (GRC-RHN0) wrote:
>> I believe adding a warning statement would be quite useful.  =20
>> Perhaps something like -
>>
>> "When using SDNVs in protocol headers use of checksums is highly =20
>> recommended.  For example: an error which flips the last
>> bit of a byte could turn one SDNV into two, or two into one, and =20
>> completely break parsing of a protocol format built out of sequential
>> SDNVs, as every SDNV is now misplaced in sequence."
>>
>>
>> It seems to me that such a statement would strengthen the document.
>>
>> Will
>>
>>
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On
>>> Behalf Of Stephen Farrell
>>> Sent: Wednesday, February 18, 2009 6:00 AM
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>>>
>>>
>>> So I've thought about this & disagree with the idea that this
>>> document should discourage anything. It'd be fine to have
>>> some motherhood and apple-pie statement that checksums etc
>>> are good but this isn't the document for a lecture on
>>> protocol design for reliability. Nor, for example, would the
>>> URI spec (rfc 3896) which I don't believe has such a discussion.
>>>
>>> So I don't agree that the additions Lloyd is asking for are
>>> useful. I think the document is fine as-is in that respect.
>>>
>>> Stephen.
>>>
>>> PS: Rather than treating everything as a reliability nail,
>>> I'd prefer that we get draft-irtf-bundle-checksum hammer
>>> finished. Where are we with that?
>>>
>>>
>>>
>>> [email-masked] wrote:
>>>> The SDNV draft needs to warn about use of SDNVs in protocol headers
>>>> which are not protected by checksums, where an error
>>> flipping the last
>>>> bit of a byte turns one SDNV into two, or two into one, and
>>> completely
>>>> breaks parsing of a complex protocol format built out of sequential
>>>> SDNVs, as every SDNV is now misplaced in sequence.
>>>>
>>>> Use of SDNVs in protocol headers - especially protocol headers not
>>>> protected by some form of reliability check thanks to the
>>> benefits of
>>>> mutable canonicalisation - needs to be discouraged. Use of
>>> protocols
>>>> dependent on SDNVs without reliability checks ensuring
>>> robustness of
>>>> SDNVs needs to be strongly discouraged for this reason.
>>>>
>>>> (There are good reasons for fixed-length fields. And good
>>> reasons for
>>>> checksums.)
>>>>
>>>> L.
>>>>
>>>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] on
>>> behalf of
>>>> Stephen Farrell
>>>> Sent: Tue 2009-02-17 18:35
>>>> To: DTN
>>>> Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>>>>
>>>>
>>>> Folks,
>>>>
>>>> We've got our first "last call" victim:-)
>>>>
>>>> Wes reckons that the SDNV draft [1] is ready to become an
>>>> informational RFC.
>>>>
>>>> Can you read and comment on this in the next month, i.e.
>>>> before the end of March 17th.
>>>>
>>>> Please bear in mind that as an IRTF RG, and not an IETF WG,
>>> we do not
>>>> need to establish rough consensus for documents, but if we do have
>>>> that its a good thing.
>>>> For the later stages of review, it's useful if folks have said "I
>>>> agree, its ok and its ready" or equivalent so please do
>>> send a mail to
>>>> the list saying that if it applies. (Preserving the subject
>>> line so we
>>>> can just add a link in the tracker later.)
>>>>
>>>> Thanks,
>>>> Stephen.
>>>>
>>>> PS: I've at least one comment - some references are now out
>>> of date:-)
>>>> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
>>>>
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer =20
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

------_=_NextPart_001_01C991E2.D921221B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Unfortunately, reliability isn't a security issue (and =
attempting to<BR>
treat it as such has its own problems, as we've seen.)<BR>
<BR>
Calling this out solely in the *security* section as a security<BR>
issue is not sufficient, imo.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Hans Kruse<BR>
Sent: Wed 2009-02-18 15:19<BR>
To: Delay Tolerant Networking Interest List<BR>
Subject: Re: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv<BR>
<BR>
I am in favor of moving the document forward as-is (no =
additional&nbsp;<BR>
disclaimer of recommendation).&nbsp; The security section =
appropriately&nbsp;<BR>
calls for validity checking during the decode.&nbsp; Once any =
protocol&nbsp;<BR>
header (whether it contains SDNVs or not) contains undetected =
errors,&nbsp;<BR>
bad things happen.&nbsp; The present security language, while aimed =
at&nbsp;<BR>
intentionally malformed packets, is IMHO sufficient warning.<BR>
<BR>
<BR>
On Feb 18, 2009, at 10:00 AM, Stephen Farrell wrote:<BR>
<BR>
&gt;<BR>
&gt; I think its clear from previous discussions that the =
&quot;highly<BR>
&gt; recommended&quot; phrase you suggest does not have broad =
support.<BR>
&gt; (My read is that people are fine with having the option to<BR>
&gt; add checksums, and are waiting for the spec for that to<BR>
&gt; complete, but I only see you guys constantly saying that<BR>
&gt; they're required.)<BR>
&gt;<BR>
&gt; So adding such phraseology is IMO inappropriate in this case<BR>
&gt; since it makes an otherwise uncontroversial and useful document<BR>
&gt; into something that's being used as part of an unrelated<BR>
&gt; argument. That's independent or the merit, or lack of merit,<BR>
&gt; of the argument so I reckon that entwining things like that<BR>
&gt; is not useful.<BR>
&gt;<BR>
&gt; And to be clear: I'm not accusing anyone here of bad will, I<BR>
&gt; just think there's no need and no benefit in dragging this<BR>
&gt; argument into every single thing.<BR>
&gt;<BR>
&gt; Stephen.<BR>
&gt;<BR>
&gt; Ivancic, William D. (GRC-RHN0) wrote:<BR>
&gt;&gt; I believe adding a warning statement would be quite =
useful.&nbsp;&nbsp;<BR>
&gt;&gt; Perhaps something like -<BR>
&gt;&gt;<BR>
&gt;&gt; &quot;When using SDNVs in protocol headers use of checksums is =
highly&nbsp;<BR>
&gt;&gt; recommended.&nbsp; For example: an error which flips the =
last<BR>
&gt;&gt; bit of a byte could turn one SDNV into two, or two into one, =
and&nbsp;<BR>
&gt;&gt; completely break parsing of a protocol format built out of =
sequential<BR>
&gt;&gt; SDNVs, as every SDNV is now misplaced in sequence.&quot;<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; It seems to me that such a statement would strengthen the =
document.<BR>
&gt;&gt;<BR>
&gt;&gt; Will<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt;&gt; -----Original Message-----<BR>
&gt;&gt;&gt; From: [email-masked]<BR>
&gt;&gt;&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:=
[email-masked]</A>] On<BR>
&gt;&gt;&gt; Behalf Of Stephen Farrell<BR>
&gt;&gt;&gt; Sent: Wednesday, February 18, 2009 6:00 AM<BR>
&gt;&gt;&gt; To: [email-masked]<BR>
&gt;&gt;&gt; Cc: [email-masked]<BR>
&gt;&gt;&gt; Subject: Re: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt; So I've thought about this &amp; disagree with the idea =
that this<BR>
&gt;&gt;&gt; document should discourage anything. It'd be fine to =
have<BR>
&gt;&gt;&gt; some motherhood and apple-pie statement that checksums =
etc<BR>
&gt;&gt;&gt; are good but this isn't the document for a lecture on<BR>
&gt;&gt;&gt; protocol design for reliability. Nor, for example, would =
the<BR>
&gt;&gt;&gt; URI spec (rfc 3896) which I don't believe has such a =
discussion.<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt; So I don't agree that the additions Lloyd is asking for =
are<BR>
&gt;&gt;&gt; useful. I think the document is fine as-is in that =
respect.<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt; Stephen.<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt; PS: Rather than treating everything as a reliability =
nail,<BR>
&gt;&gt;&gt; I'd prefer that we get draft-irtf-bundle-checksum =
hammer<BR>
&gt;&gt;&gt; finished. Where are we with that?<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt; [email-masked] wrote:<BR>
&gt;&gt;&gt;&gt; The SDNV draft needs to warn about use of SDNVs in =
protocol headers<BR>
&gt;&gt;&gt;&gt; which are not protected by checksums, where an =
error<BR>
&gt;&gt;&gt; flipping the last<BR>
&gt;&gt;&gt;&gt; bit of a byte turns one SDNV into two, or two into one, =
and<BR>
&gt;&gt;&gt; completely<BR>
&gt;&gt;&gt;&gt; breaks parsing of a complex protocol format built out =
of sequential<BR>
&gt;&gt;&gt;&gt; SDNVs, as every SDNV is now misplaced in sequence.<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; Use of SDNVs in protocol headers - especially protocol =
headers not<BR>
&gt;&gt;&gt;&gt; protected by some form of reliability check thanks to =
the<BR>
&gt;&gt;&gt; benefits of<BR>
&gt;&gt;&gt;&gt; mutable canonicalisation - needs to be discouraged. Use =
of<BR>
&gt;&gt;&gt; protocols<BR>
&gt;&gt;&gt;&gt; dependent on SDNVs without reliability checks =
ensuring<BR>
&gt;&gt;&gt; robustness of<BR>
&gt;&gt;&gt;&gt; SDNVs needs to be strongly discouraged for this =
reason.<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; (There are good reasons for fixed-length fields. And =
good<BR>
&gt;&gt;&gt; reasons for<BR>
&gt;&gt;&gt;&gt; checksums.)<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; L.<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; &lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; -----Original Message-----<BR>
&gt;&gt;&gt;&gt; From: [email-masked] =
on<BR>
&gt;&gt;&gt; behalf of<BR>
&gt;&gt;&gt;&gt; Stephen Farrell<BR>
&gt;&gt;&gt;&gt; Sent: Tue 2009-02-17 18:35<BR>
&gt;&gt;&gt;&gt; To: DTN<BR>
&gt;&gt;&gt;&gt; Subject: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; Folks,<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; We've got our first &quot;last call&quot; victim:-)<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; Wes reckons that the SDNV draft [1] is ready to become =
an<BR>
&gt;&gt;&gt;&gt; informational RFC.<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; Can you read and comment on this in the next month, =
i.e.<BR>
&gt;&gt;&gt;&gt; before the end of March 17th.<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; Please bear in mind that as an IRTF RG, and not an IETF =
WG,<BR>
&gt;&gt;&gt; we do not<BR>
&gt;&gt;&gt;&gt; need to establish rough consensus for documents, but if =
we do have<BR>
&gt;&gt;&gt;&gt; that its a good thing.<BR>
&gt;&gt;&gt;&gt; For the later stages of review, it's useful if folks =
have said &quot;I<BR>
&gt;&gt;&gt;&gt; agree, its ok and its ready&quot; or equivalent so =
please do<BR>
&gt;&gt;&gt; send a mail to<BR>
&gt;&gt;&gt;&gt; the list saying that if it applies. (Preserving the =
subject<BR>
&gt;&gt;&gt; line so we<BR>
&gt;&gt;&gt;&gt; can just add a link in the tracker later.)<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; Thanks,<BR>
&gt;&gt;&gt;&gt; Stephen.<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; PS: I've at least one comment - some references are now =
out<BR>
&gt;&gt;&gt; of date:-)<BR>
&gt;&gt;&gt;&gt; [1] <A =
HREF=3D"http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv">http://tools.ie=
tf.org/html/draft-irtf-dtnrg-sdnv</A><BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt;&gt; _______________________________________________<BR>
&gt;&gt;&gt;&gt; dtn-interest mailing list<BR>
&gt;&gt;&gt;&gt; [email-masked]<BR>
&gt;&gt;&gt;&gt; <A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
&gt;&gt;&gt;&gt;<BR>
&gt;&gt;&gt; _______________________________________________<BR>
&gt;&gt;&gt; dtn-interest mailing list<BR>
&gt;&gt;&gt; [email-masked]<BR>
&gt;&gt;&gt; <A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
&gt;&gt;&gt;<BR>
&gt; _______________________________________________<BR>
&gt; dtn-interest mailing list<BR>
&gt; [email-masked]<BR>
&gt; <A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
<BR>
Hans Kruse, Professor<BR>
J. Warren McClure School of Information and Telecommunication =
Systems<BR>
Adjunct Associate Professor of Electrical Engineering and =
Computer&nbsp;<BR>
Science<BR>
292 Lindley Hall, Ohio University, Athens, OH, 45701<BR>
740-593-4891 voice, 740-593-4889 fax<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C991E2.D921221B--

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 15:54:41 +0000
From: "Edwards, William L (Will)" <[email-masked]>
To: Jim Wyllie <[email-masked]>, "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

I am the new guy involved with this protocol and after reading the doc I
tend to favor what Will has put forth.  The use of SDNVs in protocol
headers use of checksums should be encouraged.  
Bill

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Jim Wyllie
Sent: Wednesday, February 18, 2009 9:44 AM
To: Ivancic, William D. (GRC-RHN0)
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

I agree with Will here -- It's a good, succinct observation that slight
mangling in the SDNV can cause large problems.  A discouragement is
probably a bit out of line (as pointed out, this isn't the right place
for it) but it's worth the paragraph.

> I believe adding a warning statement would be quite useful.  Perhaps
> something like -
> 
> "When using SDNVs in protocol headers use of checksums is highly
> recommended.  For example: an error which flips the last bit of a
> byte could turn one SDNV into two, or two into one, and completely
> break parsing of a protocol format built out of sequential SDNVs, as
> every SDNV is now misplaced in sequence."
> 
> 
> It seems to me that such a statement would strengthen the document.
> 
> Will
> 
> 
> 
>> -----Original Message----- From:
>> [email-masked] 
>> [mailto:[email-masked]] On 
>> Behalf Of Stephen Farrell Sent: Wednesday, February 18, 2009 6:00
>> AM To: [email-masked] Cc: [email-masked] 
>> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>> 
>> 
>> 
>> So I've thought about this & disagree with the idea that this 
>> document should discourage anything. It'd be fine to have some
>> motherhood and apple-pie statement that checksums etc are good but
>> this isn't the document for a lecture on protocol design for
>> reliability. Nor, for example, would the URI spec (rfc 3896) which
>> I don't believe has such a discussion.
>> 
>> So I don't agree that the additions Lloyd is asking for are useful.
>> I think the document is fine as-is in that respect.
>> 
>> Stephen.
>> 
>> PS: Rather than treating everything as a reliability nail, I'd
>> prefer that we get draft-irtf-bundle-checksum hammer finished.
>> Where are we with that?
>> 
>> 
>> 
>> [email-masked] wrote:
>>> The SDNV draft needs to warn about use of SDNVs in protocol
>>> headers which are not protected by checksums, where an error
>> flipping the last
>>> bit of a byte turns one SDNV into two, or two into one, and
>> completely
>>> breaks parsing of a complex protocol format built out of
>>> sequential SDNVs, as every SDNV is now misplaced in sequence.
>>> 
>>> Use of SDNVs in protocol headers - especially protocol headers
>>> not protected by some form of reliability check thanks to the
>> benefits of
>>> mutable canonicalisation - needs to be discouraged. Use of
>> protocols
>>> dependent on SDNVs without reliability checks ensuring
>> robustness of
>>> SDNVs needs to be strongly discouraged for this reason.
>>> 
>>> (There are good reasons for fixed-length fields. And good
>> reasons for
>>> checksums.)
>>> 
>>> L.
>>> 
>>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>> 
>>> 
>>> 
>>> 
>>> -----Original Message----- From:
>>> [email-masked] on
>> behalf of
>>> Stephen Farrell Sent: Tue 2009-02-17 18:35 To: DTN Subject:
>>> [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>>> 
>>> 
>>> Folks,
>>> 
>>> We've got our first "last call" victim:-)
>>> 
>>> Wes reckons that the SDNV draft [1] is ready to become an 
>>> informational RFC.
>>> 
>>> Can you read and comment on this in the next month, i.e. before
>>> the end of March 17th.
>>> 
>>> Please bear in mind that as an IRTF RG, and not an IETF WG,
>> we do not
>>> need to establish rough consensus for documents, but if we do
>>> have that its a good thing. For the later stages of review, it's
>>> useful if folks have said "I agree, its ok and its ready" or
>>> equivalent so please do
>> send a mail to
>>> the list saying that if it applies. (Preserving the subject
>> line so we
>>> can just add a link in the tracker later.)
>>> 
>>> Thanks, Stephen.
>>> 
>>> PS: I've at least one comment - some references are now out
>> of date:-)
>>> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
>>> 
>>> 
>>> _______________________________________________ dtn-interest
>>> mailing list [email-masked] 
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>> 
>>> 
>> _______________________________________________ dtn-interest
>> mailing list [email-masked] 
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
> _______________________________________________ dtn-interest mailing
> list [email-masked] 
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

-- 
Jim Wyllie
Master's Student
IRG Lab, School of EE and CS
Ohio University

From: Hans Kruse <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Wed, 18 Feb 2009 10:19:01 -0500
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

--Apple-Mail-1--1034896101
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I am in favor of moving the document forward as-is (no additional  
disclaimer of recommendation).  The security section appropriately  
calls for validity checking during the decode.  Once any protocol  
header (whether it contains SDNVs or not) contains undetected errors,  
bad things happen.  The present security language, while aimed at  
intentionally malformed packets, is IMHO sufficient warning.

On Feb 18, 2009, at 10:00 AM, Stephen Farrell wrote:

>
> I think its clear from previous discussions that the "highly
> recommended" phrase you suggest does not have broad support.
> (My read is that people are fine with having the option to
> add checksums, and are waiting for the spec for that to
> complete, but I only see you guys constantly saying that
> they're required.)
>
> So adding such phraseology is IMO inappropriate in this case
> since it makes an otherwise uncontroversial and useful document
> into something that's being used as part of an unrelated
> argument. That's independent or the merit, or lack of merit,
> of the argument so I reckon that entwining things like that
> is not useful.
>
> And to be clear: I'm not accusing anyone here of bad will, I
> just think there's no need and no benefit in dragging this
> argument into every single thing.
>
> Stephen.
>
> Ivancic, William D. (GRC-RHN0) wrote:
>> I believe adding a warning statement would be quite useful.   
>> Perhaps something like -
>>
>> "When using SDNVs in protocol headers use of checksums is highly  
>> recommended.  For example: an error which flips the last
>> bit of a byte could turn one SDNV into two, or two into one, and  
>> completely break parsing of a protocol format built out of sequential
>> SDNVs, as every SDNV is now misplaced in sequence."
>>
>>
>> It seems to me that such a statement would strengthen the document.
>>
>> Will
>>
>>
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On
>>> Behalf Of Stephen Farrell
>>> Sent: Wednesday, February 18, 2009 6:00 AM
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>>>
>>>
>>> So I've thought about this & disagree with the idea that this
>>> document should discourage anything. It'd be fine to have
>>> some motherhood and apple-pie statement that checksums etc
>>> are good but this isn't the document for a lecture on
>>> protocol design for reliability. Nor, for example, would the
>>> URI spec (rfc 3896) which I don't believe has such a discussion.
>>>
>>> So I don't agree that the additions Lloyd is asking for are
>>> useful. I think the document is fine as-is in that respect.
>>>
>>> Stephen.
>>>
>>> PS: Rather than treating everything as a reliability nail,
>>> I'd prefer that we get draft-irtf-bundle-checksum hammer
>>> finished. Where are we with that?
>>>
>>>
>>>
>>> [email-masked] wrote:
>>>> The SDNV draft needs to warn about use of SDNVs in protocol headers
>>>> which are not protected by checksums, where an error
>>> flipping the last
>>>> bit of a byte turns one SDNV into two, or two into one, and
>>> completely
>>>> breaks parsing of a complex protocol format built out of sequential
>>>> SDNVs, as every SDNV is now misplaced in sequence.
>>>>
>>>> Use of SDNVs in protocol headers - especially protocol headers not
>>>> protected by some form of reliability check thanks to the
>>> benefits of
>>>> mutable canonicalisation - needs to be discouraged. Use of
>>> protocols
>>>> dependent on SDNVs without reliability checks ensuring
>>> robustness of
>>>> SDNVs needs to be strongly discouraged for this reason.
>>>>
>>>> (There are good reasons for fixed-length fields. And good
>>> reasons for
>>>> checksums.)
>>>>
>>>> L.
>>>>
>>>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] on
>>> behalf of
>>>> Stephen Farrell
>>>> Sent: Tue 2009-02-17 18:35
>>>> To: DTN
>>>> Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>>>>
>>>>
>>>> Folks,
>>>>
>>>> We've got our first "last call" victim:-)
>>>>
>>>> Wes reckons that the SDNV draft [1] is ready to become an
>>>> informational RFC.
>>>>
>>>> Can you read and comment on this in the next month, i.e.
>>>> before the end of March 17th.
>>>>
>>>> Please bear in mind that as an IRTF RG, and not an IETF WG,
>>> we do not
>>>> need to establish rough consensus for documents, but if we do have
>>>> that its a good thing.
>>>> For the later stages of review, it's useful if folks have said "I
>>>> agree, its ok and its ready" or equivalent so please do
>>> send a mail to
>>>> the list saying that if it applies. (Preserving the subject
>>> line so we
>>>> can just add a link in the tracker later.)
>>>>
>>>> Thanks,
>>>> Stephen.
>>>>
>>>> PS: I've at least one comment - some references are now out
>>> of date:-)
>>>> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
>>>>
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-1--1034896101
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I am in favor of moving the =
document forward as-is (no additional disclaimer of recommendation). =
&nbsp;The security section appropriately calls for validity checking =
during the decode. &nbsp;Once any protocol header (whether it contains =
SDNVs or not) contains undetected errors, bad things happen. &nbsp;The =
present security language, while aimed at intentionally malformed =
packets, is IMHO sufficient warning.<div><br></div><div><br><div><div>On =
Feb 18, 2009, at 10:00 AM, Stephen Farrell wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><br>I =
think its clear from previous discussions that the =
"highly<br>recommended" phrase you suggest does not have broad =
support.<br>(My read is that people are fine with having the option =
to<br>add checksums, and are waiting for the spec for that =
to<br>complete, but I only see you guys constantly saying =
that<br>they're required.)<br><br>So adding such phraseology is IMO =
inappropriate in this case<br>since it makes an otherwise =
uncontroversial and useful document<br>into something that's being used =
as part of an unrelated<br>argument. That's independent or the merit, or =
lack of merit,<br>of the argument so I reckon that entwining things like =
that<br>is not useful.<br><br>And to be clear: I'm not accusing anyone =
here of bad will, I<br>just think there's no need and no benefit in =
dragging this<br>argument into every single =
thing.<br><br>Stephen.<br><br>Ivancic, William D. (GRC-RHN0) =
wrote:<br><blockquote type=3D"cite">I believe adding a warning statement =
would be quite useful. &nbsp;Perhaps something like =
-<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">"When using SDNVs in protocol headers use of checksums is =
highly recommended. &nbsp;For example: an error which flips the last =
<br></blockquote><blockquote type=3D"cite">bit of a byte could turn one =
SDNV into two, or two into one, and completely break parsing of a =
protocol format built out of sequential <br></blockquote><blockquote =
type=3D"cite">SDNVs, as every SDNV is now misplaced in =
sequence."<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">It seems to me =
that such a statement would strengthen the =
document.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Will<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">-----Original =
Message-----<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">From: <a =
href=3D"mailto:[email-masked]">dtn-inte=
[email-masked]</a> =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">[<a =
href=3D"mailto:[email-masked]">mailto:d=
[email-masked]</a>] On =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">Behalf Of Stephen =
Farrell<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite">Sent: Wednesday, February 18, 2009 6:00 =
AM<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">To: <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br></blockquot=
e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">Cc: =
<a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite">Subject: Re: [dtn-interest] RG "last call" on =
draft-irtf-dtnrg-sdnv<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">So I've thought about this &amp; =
disagree with the idea that this =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">document should discourage anything. It'd be fine to have =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">some motherhood and apple-pie statement that checksums etc =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">are good but this isn't the document for a lecture on =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">protocol design for reliability. Nor, for example, would =
the <br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">URI spec (rfc 3896) which I don't believe has such a =
discussion.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">So I don't agree that the =
additions Lloyd is asking for are =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">useful. I think the document is fine as-is in that =
respect.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Stephen.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">PS: Rather than treating =
everything as a reliability nail, =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">I'd prefer that we get draft-irtf-bundle-checksum hammer =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">finished. Where are we with =
that?<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">[email-masked]</a> =
wrote:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">The SDNV draft needs to warn =
about use of SDNVs in protocol headers =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">which =
are not protected by checksums, where an error =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">flipping the last =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">bit of a byte turns one SDNV =
into two, or two into one, and =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">completely =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">breaks parsing of a complex =
protocol format built out of sequential =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">SDNVs, =
as every SDNV is now misplaced in =
sequence.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Use of =
SDNVs in protocol headers - especially protocol headers not =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">protected by some form of reliability check thanks to the =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">benefits of =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">mutable canonicalisation - needs =
to be discouraged. Use of =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">protocols =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">dependent on SDNVs without =
reliability checks ensuring =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">robustness of =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">SDNVs needs to be strongly =
discouraged for this =
reason.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">(There =
are good reasons for fixed-length fields. And good =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">reasons for =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">checksums.)<br></blockquote></blockquote></blockquote><block=
quote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">L.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">&lt;<a =
href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey.=
ac.uk/Personal/L.Wood/</a>>&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>><br></blockquo=
te></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">-----Original =
Message-----<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">From: =
<a =
href=3D"mailto:[email-masked]">dtn-inte=
[email-masked]</a> on =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">behalf of =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Stephen =
Farrell<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Sent: =
Tue 2009-02-17 =
18:35<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To: =
DTN<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Subject:=
 [dtn-interest] RG "last call" on =
draft-irtf-dtnrg-sdnv<br></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Folks,<br></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">We've =
got our first "last call" =
victim:-)<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Wes =
reckons that the SDNV draft [1] is ready to become an =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">informational =
RFC.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Can =
you read and comment on this in the next month, =
i.e.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">before =
the end of March =
17th.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Please =
bear in mind that as an IRTF RG, and not an IETF WG, =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">we do not =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">need to establish rough =
consensus for documents, but if we do have =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">that =
its a good thing.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">For =
the later stages of review, it's useful if folks have said "I =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">agree, =
its ok and its ready" or equivalent so please do =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">send a mail to =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">the list saying that if it =
applies. (Preserving the subject =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">line so we =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">can just add a link in the =
tracker later.)<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Thanks,<br></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Stephen.<br></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">PS: =
I've at least one comment - some references are now out =
<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">of =
date:-)<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite"><blockquote type=3D"cite">[1] <a =
href=3D"http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv">http://tools.iet=
f.org/html/draft-irtf-dtnrg-sdnv</a><br></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">dtn-interest mailing =
list<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote>______________________________=
_________________<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></div></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-1--1034896101--

Date: Wed, 18 Feb 2009 15:00:06 +0000
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

I think its clear from previous discussions that the "highly
recommended" phrase you suggest does not have broad support.
(My read is that people are fine with having the option to
add checksums, and are waiting for the spec for that to
complete, but I only see you guys constantly saying that
they're required.)

So adding such phraseology is IMO inappropriate in this case
since it makes an otherwise uncontroversial and useful document
into something that's being used as part of an unrelated
argument. That's independent or the merit, or lack of merit,
of the argument so I reckon that entwining things like that
is not useful.

And to be clear: I'm not accusing anyone here of bad will, I
just think there's no need and no benefit in dragging this
argument into every single thing.

Stephen.

Ivancic, William D. (GRC-RHN0) wrote:
> I believe adding a warning statement would be quite useful.  Perhaps something like -
> 
> "When using SDNVs in protocol headers use of checksums is highly recommended.  For example: an error which flips the last 
> bit of a byte could turn one SDNV into two, or two into one, and completely break parsing of a protocol format built out of sequential 
> SDNVs, as every SDNV is now misplaced in sequence."
> 
> 
> It seems to me that such a statement would strengthen the document.
> 
> Will
> 
>  
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On 
>> Behalf Of Stephen Farrell
>> Sent: Wednesday, February 18, 2009 6:00 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>>
>>
>> So I've thought about this & disagree with the idea that this 
>> document should discourage anything. It'd be fine to have 
>> some motherhood and apple-pie statement that checksums etc 
>> are good but this isn't the document for a lecture on 
>> protocol design for reliability. Nor, for example, would the 
>> URI spec (rfc 3896) which I don't believe has such a discussion.
>>
>> So I don't agree that the additions Lloyd is asking for are 
>> useful. I think the document is fine as-is in that respect.
>>
>> Stephen.
>>
>> PS: Rather than treating everything as a reliability nail, 
>> I'd prefer that we get draft-irtf-bundle-checksum hammer 
>> finished. Where are we with that?
>>
>>
>>
>> [email-masked] wrote:
>>> The SDNV draft needs to warn about use of SDNVs in protocol headers 
>>> which are not protected by checksums, where an error 
>> flipping the last 
>>> bit of a byte turns one SDNV into two, or two into one, and 
>> completely 
>>> breaks parsing of a complex protocol format built out of sequential 
>>> SDNVs, as every SDNV is now misplaced in sequence.
>>>
>>> Use of SDNVs in protocol headers - especially protocol headers not 
>>> protected by some form of reliability check thanks to the 
>> benefits of 
>>> mutable canonicalisation - needs to be discouraged. Use of 
>> protocols 
>>> dependent on SDNVs without reliability checks ensuring 
>> robustness of 
>>> SDNVs needs to be strongly discouraged for this reason.
>>>
>>> (There are good reasons for fixed-length fields. And good 
>> reasons for 
>>> checksums.)
>>>
>>> L.
>>>
>>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked] on 
>> behalf of 
>>> Stephen Farrell
>>> Sent: Tue 2009-02-17 18:35
>>> To: DTN
>>> Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>>>
>>>
>>> Folks,
>>>
>>> We've got our first "last call" victim:-)
>>>
>>> Wes reckons that the SDNV draft [1] is ready to become an 
>>> informational RFC.
>>>
>>> Can you read and comment on this in the next month, i.e.
>>> before the end of March 17th.
>>>
>>> Please bear in mind that as an IRTF RG, and not an IETF WG, 
>> we do not 
>>> need to establish rough consensus for documents, but if we do have 
>>> that its a good thing.
>>> For the later stages of review, it's useful if folks have said "I 
>>> agree, its ok and its ready" or equivalent so please do 
>> send a mail to 
>>> the list saying that if it applies. (Preserving the subject 
>> line so we 
>>> can just add a link in the tracker later.)
>>>
>>> Thanks,
>>> Stephen.
>>>
>>> PS: I've at least one comment - some references are now out 
>> of date:-)
>>> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>

Date: Wed, 18 Feb 2009 09:43:59 -0500
From: Jim Wyllie <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig021D30D589B097327FE439C7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree with Will here -- It's a good, succinct observation that slight
mangling in the SDNV can cause large problems.  A discouragement is
probably a bit out of line (as pointed out, this isn't the right place
for it) but it's worth the paragraph.

> I believe adding a warning statement would be quite useful.  Perhaps
> something like -
>=20
> "When using SDNVs in protocol headers use of checksums is highly
> recommended.  For example: an error which flips the last bit of a
> byte could turn one SDNV into two, or two into one, and completely
> break parsing of a protocol format built out of sequential SDNVs, as
> every SDNV is now misplaced in sequence."
>=20
>=20
> It seems to me that such a statement would strengthen the document.
>=20
> Will
>=20
>=20
>=20
>> -----Original Message----- From:
>> [email-masked]=20
>> [mailto:[email-masked]] On=20
>> Behalf Of Stephen Farrell Sent: Wednesday, February 18, 2009 6:00
>> AM To: [email-masked] Cc: [email-masked]=20
>> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>>=20
>>=20
>>=20
>> So I've thought about this & disagree with the idea that this=20
>> document should discourage anything. It'd be fine to have some
>> motherhood and apple-pie statement that checksums etc are good but
>> this isn't the document for a lecture on protocol design for
>> reliability. Nor, for example, would the URI spec (rfc 3896) which
>> I don't believe has such a discussion.
>>=20
>> So I don't agree that the additions Lloyd is asking for are useful.
>> I think the document is fine as-is in that respect.
>>=20
>> Stephen.
>>=20
>> PS: Rather than treating everything as a reliability nail, I'd
>> prefer that we get draft-irtf-bundle-checksum hammer finished.
>> Where are we with that?
>>=20
>>=20
>>=20
>> [email-masked] wrote:
>>> The SDNV draft needs to warn about use of SDNVs in protocol
>>> headers which are not protected by checksums, where an error
>> flipping the last
>>> bit of a byte turns one SDNV into two, or two into one, and
>> completely
>>> breaks parsing of a complex protocol format built out of
>>> sequential SDNVs, as every SDNV is now misplaced in sequence.
>>>=20
>>> Use of SDNVs in protocol headers - especially protocol headers
>>> not protected by some form of reliability check thanks to the
>> benefits of
>>> mutable canonicalisation - needs to be discouraged. Use of
>> protocols
>>> dependent on SDNVs without reliability checks ensuring
>> robustness of
>>> SDNVs needs to be strongly discouraged for this reason.
>>>=20
>>> (There are good reasons for fixed-length fields. And good
>> reasons for
>>> checksums.)
>>>=20
>>> L.
>>>=20
>>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>>=20
>>>=20
>>>=20
>>>=20
>>> -----Original Message----- From:
>>> [email-masked] on
>> behalf of
>>> Stephen Farrell Sent: Tue 2009-02-17 18:35 To: DTN Subject:
>>> [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
>>>=20
>>>=20
>>> Folks,
>>>=20
>>> We've got our first "last call" victim:-)
>>>=20
>>> Wes reckons that the SDNV draft [1] is ready to become an=20
>>> informational RFC.
>>>=20
>>> Can you read and comment on this in the next month, i.e. before
>>> the end of March 17th.
>>>=20
>>> Please bear in mind that as an IRTF RG, and not an IETF WG,
>> we do not
>>> need to establish rough consensus for documents, but if we do
>>> have that its a good thing. For the later stages of review, it's
>>> useful if folks have said "I agree, its ok and its ready" or
>>> equivalent so please do
>> send a mail to
>>> the list saying that if it applies. (Preserving the subject
>> line so we
>>> can just add a link in the tracker later.)
>>>=20
>>> Thanks, Stephen.
>>>=20
>>> PS: I've at least one comment - some references are now out
>> of date:-)
>>> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
>>>=20
>>>=20
>>> _______________________________________________ dtn-interest
>>> mailing list [email-masked]=20
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>=20
>>>=20
>> _______________________________________________ dtn-interest
>> mailing list [email-masked]=20
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>=20
> _______________________________________________ dtn-interest mailing
> list [email-masked]=20
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--=20
Jim Wyllie
Master's Student
IRG Lab, School of EE and CS
Ohio University

--------------enig021D30D589B097327FE439C7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig021D30D589B097327FE439C7--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 18 Feb 2009 08:30:56 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Contact Graph Routing

Scott,

Regarding Contact Graph Routing (CGR):  

Is it fair to say that CGR could be applied to any store-and-forward network and is not limited to a DTN based on bundling?

Regarding the DINET experiments:

Was CGR performed at a central source and the CGR route tables and contact times pushed out to the various forwarding nodes or were the contact times pushed out to the various forwarding nodes and the CGR routes calculated at each forwarding node?   I can see value in either approach.  For example, the centralized approach  allows one to debug at a single location which is probably quite useful for early experimentation.  

This question is a result of looking at various network management requirements. 

Will

Date: Wed, 18 Feb 2009 16:03:11 +0200
From: Teemu <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

Hi,

I've read the draft and implemented SDNV parsing. It's ok by me, although it
seems a bit heavy on the background information and motivation (e.g.,
Section 4).

Cheers,
-Teemu

On 17.2.2009 20.35, "Stephen Farrell" <[email-masked]> wrote:

> 
> Folks,
> 
> We've got our first "last call" victim:-)
> 
> Wes reckons that the SDNV draft [1] is ready to become
> an informational RFC.
> 
> Can you read and comment on this in the next month, i.e.
> before the end of March 17th.
> 
> Please bear in mind that as an IRTF RG, and not an
> IETF WG, we do not need to establish rough consensus
> for documents, but if we do have that its a good thing.
> For the later stages of review, it's useful if folks have
> said "I agree, its ok and its ready" or equivalent so
> please do send a mail to the list saying that if it
> applies. (Preserving the subject line so we can just
> add a link in the tracker later.)
> 
> Thanks,
> Stephen.
> 
> PS: I've at least one comment - some references are now
> out of date:-)
> 
> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 18 Feb 2009 08:06:14 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

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

I wouldn't call this "discouraging use".   I would call this an appropriate=
 warning that one should either use a mechanism that has a very high probab=
ility of  detect errors in the header or a mechanism that has a very high p=
robability of ensuring that no errors occur in the header, or both.  The fo=
rmer is convergence layer agnostic.

Will

________________________________
From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Burleigh, Scott C
Sent: Tuesday, February 17, 2009 3:52 PM
To: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

I think this will just be one of those points on which we won't reach conse=
nsus.  In the DINET experiment we operated a DTN for a month over very nois=
y interplanetary R/F links without any corruption of headers or data at any=
 time, thanks to the normal, quite robust CCSDS link-layer encoding.  There=
 is no need to discourage the use of SDNVs in protocol headers.

Scott

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 17, 2009 12:09 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

The SDNV draft needs to warn about use of SDNVs in protocol headers
which are not protected by checksums, where an error flipping the
last bit of a byte turns one SDNV into two, or two into one, and
completely breaks parsing of a complex protocol format built
out of sequential SDNVs, as every SDNV is now misplaced in sequence.

Use of SDNVs in protocol headers - especially protocol
headers not protected by some form of reliability check thanks to
the benefits of mutable canonicalisation - needs to be
discouraged. Use of protocols dependent on SDNVs
without reliability checks ensuring robustness of SDNVs needs
to be strongly discouraged for this reason.

(There are good reasons for fixed-length fields. And good
reasons for checksums.)

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of Stephe=
n Farrell
Sent: Tue 2009-02-17 18:35
To: DTN
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

Folks,

We've got our first "last call" victim:-)

Wes reckons that the SDNV draft [1] is ready to become
an informational RFC.

Can you read and comment on this in the next month, i.e.
before the end of March 17th.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

PS: I've at least one comment - some references are now
out of date:-)

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:m =3D=20
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD><TITLE>RE: [dtn-in=
terest] RG "last call" on draft-irtf-dtnrg-sdnv</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16809" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","seri=
f"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","seri=
f"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","seri=
f"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times =
New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: auto; mso-m=
argin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: perso=
nal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
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 vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D968290214-18022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>I wouldn't call this "discouraging use". &nbsp; I =
would=20
call this an appropriate warning that one should either use a mechanism tha=
t has=20
a very high probability of&nbsp; detect errors in the header or a mechanism=
 that=20
has a very high probability of ensuring that no errors occur in the header,=
 or=20
both.&nbsp; The former is convergence layer agnostic.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D968290214-18022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D968290214-18022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Will</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV><!-- Converted from text/plain format -->
<P><FONT size=3D2></FONT>&nbsp;</P>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli=
d; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B>=20
  [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf O=
f=20
  </B>Burleigh, Scott C<BR><B>Sent:</B> Tuesday, February 17, 2009 3:52=20
  PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Re:=20
  [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv<BR></FONT><BR></DI=
V>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-se=
rif'">I=20
  think this will just be one of those points on which we won&#8217;t reach=
=20
  consensus.&nbsp; In the DINET experiment we operated a DTN for a month ov=
er=20
  very noisy interplanetary R/F links without any corruption of headers or =
data=20
  at any time, thanks to the normal, quite robust CCSDS link-layer=20
  encoding.&nbsp; There is no need to discourage the use of SDNVs in protoc=
ol=20
  headers.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-se=
rif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-se=
rif'">Scott<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-se=
rif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: mediu=
m none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt sol=
id; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4=
df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium n=
one; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN=
></B><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20
  [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf O=
f=20
  </B>[email-masked]<BR><B>Sent:</B> Tuesday, February 17, 2009 12:09=
=20
  PM<BR><B>To:</B> [email-masked];=20
  [email-masked]<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: [dtn-interest] RG "last call" =
on=20
  draft-irtf-dtnrg-sdnv<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P style=3D"MARGIN-BOTTOM: 12pt"><SPAN style=3D"FONT-SIZE: 10pt">The SDNV=
 draft=20
  needs to warn about use of SDNVs in protocol headers<BR>which are not=20
  protected by checksums, where an error flipping the<BR>last bit of a byte=
=20
  turns one SDNV into two, or two into one, and<BR>completely breaks parsin=
g of=20
  a complex protocol format built<BR>out of sequential SDNVs, as every SDNV=
 is=20
  now misplaced in sequence.<BR><BR>Use of SDNVs in protocol headers -=20
  especially protocol<BR>headers not protected by some form of reliability =
check=20
  thanks to<BR>the benefits of mutable canonicalisation - needs to=20
  be<BR>discouraged. Use of protocols dependent on SDNVs<BR>without reliabi=
lity=20
  checks ensuring robustness of SDNVs needs<BR>to be strongly discouraged f=
or=20
  this reason.<BR><BR>(There are good reasons for fixed-length fields. And=
=20
  good<BR>reasons for checksums.)<BR><BR>L.<BR><BR>&lt;<A=20
  href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR><BR><BR><BR>-=
----Original=20
  Message-----<BR>From: [email-masked] o=
n=20
  behalf of Stephen Farrell<BR>Sent: Tue 2009-02-17 18:35<BR>To: DTN<BR>Sub=
ject:=20
  [dtn-interest] RG "last call" on=20
  draft-irtf-dtnrg-sdnv<BR><BR><BR>Folks,<BR><BR>We've got our first "last =
call"=20
  victim:-)<BR><BR>Wes reckons that the SDNV draft [1] is ready to become<B=
R>an=20
  informational RFC.<BR><BR>Can you read and comment on this in the next mo=
nth,=20
  i.e.<BR>before the end of March 17th.<BR><BR>Please bear in mind that as =
an=20
  IRTF RG, and not an<BR>IETF WG, we do not need to establish rough=20
  consensus<BR>for documents, but if we do have that its a good thing.<BR>F=
or=20
  the later stages of review, it's useful if folks have<BR>said "I agree, i=
ts ok=20
  and its ready" or equivalent so<BR>please do send a mail to the list sayi=
ng=20
  that if it<BR>applies. (Preserving the subject line so we can just<BR>add=
 a=20
  link in the tracker later.)<BR><BR>Thanks,<BR>Stephen.<BR><BR>PS: I've at=
=20
  least one comment - some references are now<BR>out of date:-)<BR><BR>[1] =
<A=20
  href=3D"http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv">http://tools.ie=
tf.org/html/draft-irtf-dtnrg-sdnv</A><BR><BR><BR>__________________________=
_____________________<BR>dtn-interest=20
  mailing list<BR>[email-masked]<BR><A=20
  href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A></SP=
AN><o:p></o:p></P></DIV></DIV></BLOCKQUOTE></BODY></HTML>

--_000_3A5AA67A8B120B48825BFFCF544385613EC0495DNDJSSCC03ndcnas_--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 18 Feb 2009 07:41:42 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

I believe adding a warning statement would be quite useful.  Perhaps something like -

"When using SDNVs in protocol headers use of checksums is highly recommended.  For example: an error which flips the last 
bit of a byte could turn one SDNV into two, or two into one, and completely break parsing of a protocol format built out of sequential 
SDNVs, as every SDNV is now misplaced in sequence."

It seems to me that such a statement would strengthen the document.

Will

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Stephen Farrell
> Sent: Wednesday, February 18, 2009 6:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
> 
> 
> So I've thought about this & disagree with the idea that this 
> document should discourage anything. It'd be fine to have 
> some motherhood and apple-pie statement that checksums etc 
> are good but this isn't the document for a lecture on 
> protocol design for reliability. Nor, for example, would the 
> URI spec (rfc 3896) which I don't believe has such a discussion.
> 
> So I don't agree that the additions Lloyd is asking for are 
> useful. I think the document is fine as-is in that respect.
> 
> Stephen.
> 
> PS: Rather than treating everything as a reliability nail, 
> I'd prefer that we get draft-irtf-bundle-checksum hammer 
> finished. Where are we with that?
> 
> 
> 
> [email-masked] wrote:
> > The SDNV draft needs to warn about use of SDNVs in protocol headers 
> > which are not protected by checksums, where an error 
> flipping the last 
> > bit of a byte turns one SDNV into two, or two into one, and 
> completely 
> > breaks parsing of a complex protocol format built out of sequential 
> > SDNVs, as every SDNV is now misplaced in sequence.
> > 
> > Use of SDNVs in protocol headers - especially protocol headers not 
> > protected by some form of reliability check thanks to the 
> benefits of 
> > mutable canonicalisation - needs to be discouraged. Use of 
> protocols 
> > dependent on SDNVs without reliability checks ensuring 
> robustness of 
> > SDNVs needs to be strongly discouraged for this reason.
> > 
> > (There are good reasons for fixed-length fields. And good 
> reasons for 
> > checksums.)
> > 
> > L.
> > 
> > <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> > 
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] on 
> behalf of 
> > Stephen Farrell
> > Sent: Tue 2009-02-17 18:35
> > To: DTN
> > Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
> > 
> > 
> > Folks,
> > 
> > We've got our first "last call" victim:-)
> > 
> > Wes reckons that the SDNV draft [1] is ready to become an 
> > informational RFC.
> > 
> > Can you read and comment on this in the next month, i.e.
> > before the end of March 17th.
> > 
> > Please bear in mind that as an IRTF RG, and not an IETF WG, 
> we do not 
> > need to establish rough consensus for documents, but if we do have 
> > that its a good thing.
> > For the later stages of review, it's useful if folks have said "I 
> > agree, its ok and its ready" or equivalent so please do 
> send a mail to 
> > the list saying that if it applies. (Preserving the subject 
> line so we 
> > can just add a link in the tracker later.)
> > 
> > Thanks,
> > Stephen.
> > 
> > PS: I've at least one comment - some references are now out 
> of date:-)
> > 
> > [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
> > 
> > 
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> > 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Wed, 18 Feb 2009 10:59:47 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

So I've thought about this & disagree with the idea that
this document should discourage anything. It'd be fine
to have some motherhood and apple-pie statement that
checksums etc are good but this isn't the document for
a lecture on protocol design for reliability. Nor, for
example, would the URI spec (rfc 3896) which I don't
believe has such a discussion.

So I don't agree that the additions Lloyd is asking
for are useful. I think the document is fine as-is
in that respect.

Stephen.

PS: Rather than treating everything as a reliability
nail, I'd prefer that we get draft-irtf-bundle-checksum
hammer finished. Where are we with that?

[email-masked] wrote:
> The SDNV draft needs to warn about use of SDNVs in protocol headers
> which are not protected by checksums, where an error flipping the
> last bit of a byte turns one SDNV into two, or two into one, and
> completely breaks parsing of a complex protocol format built
> out of sequential SDNVs, as every SDNV is now misplaced in sequence.
> 
> Use of SDNVs in protocol headers - especially protocol
> headers not protected by some form of reliability check thanks to
> the benefits of mutable canonicalisation - needs to be
> discouraged. Use of protocols dependent on SDNVs
> without reliability checks ensuring robustness of SDNVs needs
> to be strongly discouraged for this reason.
> 
> (There are good reasons for fixed-length fields. And good
> reasons for checksums.)
> 
> L.
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> -----Original Message-----
> From: [email-masked] on behalf of
> Stephen Farrell
> Sent: Tue 2009-02-17 18:35
> To: DTN
> Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
> 
> 
> Folks,
> 
> We've got our first "last call" victim:-)
> 
> Wes reckons that the SDNV draft [1] is ready to become
> an informational RFC.
> 
> Can you read and comment on this in the next month, i.e.
> before the end of March 17th.
> 
> Please bear in mind that as an IRTF RG, and not an
> IETF WG, we do not need to establish rough consensus
> for documents, but if we do have that its a good thing.
> For the later stages of review, it's useful if folks have
> said "I agree, its ok and its ready" or equivalent so
> please do send a mail to the list saying that if it
> applies. (Preserving the subject line so we can just
> add a link in the tracker later.)
> 
> Thanks,
> Stephen.
> 
> PS: I've at least one comment - some references are now
> out of date:-)
> 
> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 10:36:32 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: [dtn-interest] detecting errors was RE: RG "last call" on draft-irtf-dtnrg-sdnv

This is a multi-part message in MIME format.

------_=_NextPart_001_01C991B5.65DB113B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No, it's not the convergence layer's job to provide FEC.
(And the end-to-end principle tells us that wouldn't be
enough to be certain that there were no errors.)

What the convergence layer's job _is_ has never been clearly
defined, and different convergence layers (UDP, TCP, etc.) do
different things with different behaviours.

Most convergence layers do not do FEC.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Peter TB Brett
Sent: Tue 2009-02-17 23:14
To: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
=20
On Tuesday 17 February 2009 22:10:59 [email-masked] wrote:

> Since the bundle protocol does not do a good job of detecting errors =
in its
> structures or metadata (and often no job - custody transfer reports =
are no
> indication that a bundle was transferred _reliably_) this is exactly =
what
> can happen when errors are passed up to the bundle.

Isn't it the convergence layer's job to apply FEC as appropriate to the=20
particular link conditions it is abstracting?

                                      Peter

--=20
Peter Brett

Electronic Systems Engineer
Integral Informatics Ltd

------_=_NextPart_001_01C991B5.65DB113B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>detecting errors was RE: RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>No, it's not the convergence layer's job to provide =
FEC.<BR>
(And the end-to-end principle tells us that wouldn't be<BR>
enough to be certain that there were no errors.)<BR>
<BR>
What the convergence layer's job _is_ has never been clearly<BR>
defined, and different convergence layers (UDP, TCP, etc.) do<BR>
different things with different behaviours.<BR>
<BR>
Most convergence layers do not do FEC.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Peter TB Brett<BR>
Sent: Tue 2009-02-17 23:14<BR>
To: [email-masked]<BR>
Subject: Re: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv<BR>
<BR>
On Tuesday 17 February 2009 22:10:59 [email-masked] wrote:<BR>
<BR>
&gt; Since the bundle protocol does not do a good job of detecting =
errors in its<BR>
&gt; structures or metadata (and often no job - custody transfer reports =
are no<BR>
&gt; indication that a bundle was transferred _reliably_) this is =
exactly what<BR>
&gt; can happen when errors are passed up to the bundle.<BR>
<BR>
Isn't it the convergence layer's job to apply FEC as appropriate to =
the<BR>
particular link conditions it is abstracting?<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; Peter<BR>
<BR>
--<BR>
Peter Brett<BR>
<BR>
Electronic Systems Engineer<BR>
Integral Informatics Ltd<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C991B5.65DB113B--

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: Peter TB Brett <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Feb 2009 18:21:31 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

Can replies change the subject line on this thread?  We've now strayed quite
far from the draft in question which isn't even about the bundle protocol
specifically ...

From: Peter TB Brett <[email-masked]>
Organization: Integral Informatics Ltd
To: [email-masked]
Date: Tue, 17 Feb 2009 23:14:12 +0000
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

--nextPart3961009.nUZQRcuphM
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 17 February 2009 22:10:59 [email-masked] wrote:

> Since the bundle protocol does not do a good job of detecting errors in i=
ts
> structures or metadata (and often no job - custody transfer reports are no
> indication that a bundle was transferred _reliably_) this is exactly what
> can happen when errors are passed up to the bundle.

Isn't it the convergence layer's job to apply FEC as appropriate to the=20
particular link conditions it is abstracting?

                                      Peter

=2D-=20
Peter Brett

Electronic Systems Engineer
Integral Informatics Ltd

--nextPart3961009.nUZQRcuphM
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart3961009.nUZQRcuphM--

Content-class: urn:content-classes:message
Date: Tue, 17 Feb 2009 22:10:59 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9914C.9CDE4D17
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Scott,

please define 'noisy'. The predictable, well-characterised, =
heavily-FEC'd
physical channels of deep space links are not the varying disrupted
physical channels of mobile ad-hoc networks, where your experience =
simply
does not apply.

Also, Kevin has often stressed that the door should be left open for
bit errors to be passed up the stack to the applications, for =
applications
to take advantage of errored data and handle the errored data =
themselves.

Since the bundle protocol does not do a good job of detecting errors in =
its
structures or metadata (and often no job - custody transfer reports are =
no
indication that a bundle was transferred _reliably_) this is exactly =
what
can happen when errors are passed up to the bundle.

A bundle protocol actually really designed to tolerate errors in =
payloads
while protecting structure and header/metadata fields from errors would
be designed and structured considerably differently, I think.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Burleigh, Scott C
Sent: Tue 2009-02-17 20:52
To: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
=20
I think this will just be one of those points on which we won't reach =
consensus.  In the DINET experiment we operated a DTN for a month over =
very noisy interplanetary R/F links without any corruption of headers or =
data at any time, thanks to the normal, quite robust CCSDS link-layer =
encoding.  There is no need to discourage the use of SDNVs in protocol =
headers.

Scott

From: [email-masked] =
[mailto:[email-masked]] On Behalf Of =
[email-masked]
Sent: Tuesday, February 17, 2009 12:09 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

The SDNV draft needs to warn about use of SDNVs in protocol headers
which are not protected by checksums, where an error flipping the
last bit of a byte turns one SDNV into two, or two into one, and
completely breaks parsing of a complex protocol format built
out of sequential SDNVs, as every SDNV is now misplaced in sequence.

Use of SDNVs in protocol headers - especially protocol
headers not protected by some form of reliability check thanks to
the benefits of mutable canonicalisation - needs to be
discouraged. Use of protocols dependent on SDNVs
without reliability checks ensuring robustness of SDNVs needs
to be strongly discouraged for this reason.

(There are good reasons for fixed-length fields. And good
reasons for checksums.)

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Stephen Farrell
Sent: Tue 2009-02-17 18:35
To: DTN
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

Folks,

We've got our first "last call" victim:-)

Wes reckons that the SDNV draft [1] is ready to become
an informational RFC.

Can you read and comment on this in the next month, i.e.
before the end of March 17th.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

PS: I've at least one comment - some references are now
out of date:-)

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------_=_NextPart_001_01C9914C.9CDE4D17
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Scott,<BR>
<BR>
please define 'noisy'. The predictable, well-characterised, =
heavily-FEC'd<BR>
physical channels of deep space links are not the varying disrupted<BR>
physical channels of mobile ad-hoc networks, where your experience =
simply<BR>
does not apply.<BR>
<BR>
Also, Kevin has often stressed that the door should be left open for<BR>
bit errors to be passed up the stack to the applications, for =
applications<BR>
to take advantage of errored data and handle the errored data =
themselves.<BR>
<BR>
Since the bundle protocol does not do a good job of detecting errors in =
its<BR>
structures or metadata (and often no job - custody transfer reports are =
no<BR>
indication that a bundle was transferred _reliably_) this is exactly =
what<BR>
can happen when errors are passed up to the bundle.<BR>
<BR>
A bundle protocol actually really designed to tolerate errors in =
payloads<BR>
while protecting structure and header/metadata fields from errors =
would<BR>
be designed and structured considerably differently, I think.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Burleigh, Scott C<BR>
Sent: Tue 2009-02-17 20:52<BR>
To: [email-masked]<BR>
Subject: Re: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv<BR>
<BR>
I think this will just be one of those points on which we won't reach =
consensus.&nbsp; In the DINET experiment we operated a DTN for a month =
over very noisy interplanetary R/F links without any corruption of =
headers or data at any time, thanks to the normal, quite robust CCSDS =
link-layer encoding.&nbsp; There is no need to discourage the use of =
SDNVs in protocol headers.<BR>
<BR>
Scott<BR>
<BR>
From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:=
[email-masked]</A>] On Behalf Of =
[email-masked]<BR>
Sent: Tuesday, February 17, 2009 12:09 PM<BR>
To: [email-masked]; [email-masked]<BR>
Cc: [email-masked]<BR>
Subject: Re: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv<BR>
<BR>
<BR>
The SDNV draft needs to warn about use of SDNVs in protocol headers<BR>
which are not protected by checksums, where an error flipping the<BR>
last bit of a byte turns one SDNV into two, or two into one, and<BR>
completely breaks parsing of a complex protocol format built<BR>
out of sequential SDNVs, as every SDNV is now misplaced in sequence.<BR>
<BR>
Use of SDNVs in protocol headers - especially protocol<BR>
headers not protected by some form of reliability check thanks to<BR>
the benefits of mutable canonicalisation - needs to be<BR>
discouraged. Use of protocols dependent on SDNVs<BR>
without reliability checks ensuring robustness of SDNVs needs<BR>
to be strongly discouraged for this reason.<BR>
<BR>
(There are good reasons for fixed-length fields. And good<BR>
reasons for checksums.)<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Stephen Farrell<BR>
Sent: Tue 2009-02-17 18:35<BR>
To: DTN<BR>
Subject: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv<BR>
<BR>
<BR>
Folks,<BR>
<BR>
We've got our first &quot;last call&quot; victim:-)<BR>
<BR>
Wes reckons that the SDNV draft [1] is ready to become<BR>
an informational RFC.<BR>
<BR>
Can you read and comment on this in the next month, i.e.<BR>
before the end of March 17th.<BR>
<BR>
Please bear in mind that as an IRTF RG, and not an<BR>
IETF WG, we do not need to establish rough consensus<BR>
for documents, but if we do have that its a good thing.<BR>
For the later stages of review, it's useful if folks have<BR>
said &quot;I agree, its ok and its ready&quot; or equivalent so<BR>
please do send a mail to the list saying that if it<BR>
applies. (Preserving the subject line so we can just<BR>
add a link in the tracker later.)<BR>
<BR>
Thanks,<BR>
Stephen.<BR>
<BR>
PS: I've at least one comment - some references are now<BR>
out of date:-)<BR>
<BR>
[1] <A =
HREF=3D"http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv">http://tools.ie=
tf.org/html/draft-irtf-dtnrg-sdnv</A><BR>
<BR>
<BR>
_______________________________________________<BR>
dtn-interest mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9914C.9CDE4D17--

From: "Burleigh, Scott C" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 17 Feb 2009 12:52:07 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

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

I think this will just be one of those points on which we won't reach conse=
nsus.  In the DINET experiment we operated a DTN for a month over very nois=
y interplanetary R/F links without any corruption of headers or data at any=
 time, thanks to the normal, quite robust CCSDS link-layer encoding.  There=
 is no need to discourage the use of SDNVs in protocol headers.

Scott

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 17, 2009 12:09 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

The SDNV draft needs to warn about use of SDNVs in protocol headers
which are not protected by checksums, where an error flipping the
last bit of a byte turns one SDNV into two, or two into one, and
completely breaks parsing of a complex protocol format built
out of sequential SDNVs, as every SDNV is now misplaced in sequence.

Use of SDNVs in protocol headers - especially protocol
headers not protected by some form of reliability check thanks to
the benefits of mutable canonicalisation - needs to be
discouraged. Use of protocols dependent on SDNVs
without reliability checks ensuring robustness of SDNVs needs
to be strongly discouraged for this reason.

(There are good reasons for fixed-length fields. And good
reasons for checksums.)

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of Stephe=
n Farrell
Sent: Tue 2009-02-17 18:35
To: DTN
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

Folks,

We've got our first "last call" victim:-)

Wes reckons that the SDNV draft [1] is ready to become
an informational RFC.

Can you read and comment on this in the next month, i.e.
before the end of March 17th.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

PS: I've at least one comment - some references are now
out of date:-)

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--_000_FD514C8A5155C64C9B145B48D674EF544951CD9BBCALTPHYEMBEVSP_
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:m=3D"http://schemas.microsoft.com/office/2004/12/omml" 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)">
<title>RE: [dtn-interest] RG &quot;last call&quot; on draft-irtf-dtnrg-sdnv=
</title>
<style>
<!--
 /* Font Definitions */
 @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
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>I think this will just be one of those points on which we wo=
n&#8217;t
reach consensus.&nbsp; In the DINET experiment we operated a DTN for a mont=
h over
very noisy interplanetary R/F links without any corruption of headers or da=
ta
at any time, thanks to the normal, quite robust CCSDS link-layer
encoding.&nbsp; There is no need to discourage the use of SDNVs in protocol
headers.<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'>Scott<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>

<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>[email-masked]<br>
<b>Sent:</b> Tuesday, February 17, 2009 12:09 PM<br>
<b>To:</b> [email-masked]; [email-masked]<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [dtn-interest] RG &quot;last call&quot; on
draft-irtf-dtnrg-sdnv<o:p></o:p></span></p>

</div>

</div>

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

<p style=3D'margin-bottom:12.0pt'><span style=3D'font-size:10.0pt'>The SDNV=
 draft
needs to warn about use of SDNVs in protocol headers<br>
which are not protected by checksums, where an error flipping the<br>
last bit of a byte turns one SDNV into two, or two into one, and<br>
completely breaks parsing of a complex protocol format built<br>
out of sequential SDNVs, as every SDNV is now misplaced in sequence.<br>
<br>
Use of SDNVs in protocol headers - especially protocol<br>
headers not protected by some form of reliability check thanks to<br>
the benefits of mutable canonicalisation - needs to be<br>
discouraged. Use of protocols dependent on SDNVs<br>
without reliability checks ensuring robustness of SDNVs needs<br>
to be strongly discouraged for this reason.<br>
<br>
(There are good reasons for fixed-length fields. And good<br>
reasons for checksums.)<br>
<br>
L.<br>
<br>
&lt;<a href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.s=
urrey.ac.uk/Personal/L.Wood/</a>&gt;&lt;[email-masked]&gt;<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: [email-masked] on behalf of Stephe=
n
Farrell<br>
Sent: Tue 2009-02-17 18:35<br>
To: DTN<br>
Subject: [dtn-interest] RG &quot;last call&quot; on draft-irtf-dtnrg-sdnv<b=
r>
<br>
<br>
Folks,<br>
<br>
We've got our first &quot;last call&quot; victim:-)<br>
<br>
Wes reckons that the SDNV draft [1] is ready to become<br>
an informational RFC.<br>
<br>
Can you read and comment on this in the next month, i.e.<br>
before the end of March 17th.<br>
<br>
Please bear in mind that as an IRTF RG, and not an<br>
IETF WG, we do not need to establish rough consensus<br>
for documents, but if we do have that its a good thing.<br>
For the later stages of review, it's useful if folks have<br>
said &quot;I agree, its ok and its ready&quot; or equivalent so<br>
please do send a mail to the list saying that if it<br>
applies. (Preserving the subject line so we can just<br>
add a link in the tracker later.)<br>
<br>
Thanks,<br>
Stephen.<br>
<br>
PS: I've at least one comment - some references are now<br>
out of date:-)<br>
<br>
[1] <a href=3D"http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv">http://too=
ls.ietf.org/html/draft-irtf-dtnrg-sdnv</a><br>
<br>
<br>
_______________________________________________<br>
dtn-interest mailing list<br>
[email-masked]<br>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a></s=
pan><o:p></o:p></p>

</div>

</div>

</body>

</html>

--_000_FD514C8A5155C64C9B145B48D674EF544951CD9BBCALTPHYEMBEVSP_--

Content-class: urn:content-classes:message
Date: Tue, 17 Feb 2009 20:27:14 -0000
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Hidden Minneapolis meeting minutes?

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9913E.62152301
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks.

It would be a shame if the details of the two separate tests
of the Bundle Protocol in space weren't included in the proceedings
solely due to administrative delay.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tue 2009-02-17 18:50
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]
Subject: Re: [dtn-interest] Hidden Minneapolis meeting minutes?
=20

I've asked. We'll see.
S.

Lloyd Wood wrote:
> The Minneapolis DTNRG meeting slides at:
> http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html
> are not linked to directly from the main meeting proceedings page and =
frameset:
> http://www.ietf.org/proceedings/08nov/
> possibly because meeting minutes aren't included?
>=20
> The slides are a little difficult to find. Can this be corrected?
>=20
> thanks,
>=20
> L.
>=20
> Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
>=20
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>=20

------_=_NextPart_001_01C9913E.62152301
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Hidden Minneapolis meeting minutes?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Thanks.<BR>
<BR>
It would be a shame if the details of the two separate tests<BR>
of the Bundle Protocol in space weren't included in the proceedings<BR>
solely due to administrative delay.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Stephen Farrell [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
e</A>]<BR>
Sent: Tue 2009-02-17 18:50<BR>
To: Wood L Dr (Electronic Eng)<BR>
Cc: [email-masked]<BR>
Subject: Re: [dtn-interest] Hidden Minneapolis meeting minutes?<BR>
<BR>
<BR>
I've asked. We'll see.<BR>
S.<BR>
<BR>
Lloyd Wood wrote:<BR>
&gt; The Minneapolis DTNRG meeting slides at:<BR>
&gt; <A =
HREF=3D"http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html">http://w=
ww.ietf.org/proceedings/08nov/agenda/DTNRG.html</A><BR>
&gt; are not linked to directly from the main meeting proceedings page =
and frameset:<BR>
&gt; <A =
HREF=3D"http://www.ietf.org/proceedings/08nov/">http://www.ietf.org/proce=
edings/08nov/</A><BR>
&gt; possibly because meeting minutes aren't included?<BR>
&gt;<BR>
&gt; The slides are a little difficult to find. Can this be =
corrected?<BR>
&gt;<BR>
&gt; thanks,<BR>
&gt;<BR>
&gt; L.<BR>
&gt;<BR>
&gt; Saratoga: <A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/">http://www.ee.su=
rrey.ac.uk/Personal/L.Wood/dtn/</A><BR>
&gt;<BR>
&gt; &lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9913E.62152301--

Content-class: urn:content-classes:message
Date: Tue, 17 Feb 2009 20:08:40 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9913B.868C1C79
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The SDNV draft needs to warn about use of SDNVs in protocol headers
which are not protected by checksums, where an error flipping the=20
last bit of a byte turns one SDNV into two, or two into one, and
completely breaks parsing of a complex protocol format built
out of sequential SDNVs, as every SDNV is now misplaced in sequence.

Use of SDNVs in protocol headers - especially protocol
headers not protected by some form of reliability check thanks to
the benefits of mutable canonicalisation - needs to be
discouraged. Use of protocols dependent on SDNVs
without reliability checks ensuring robustness of SDNVs needs
to be strongly discouraged for this reason.

(There are good reasons for fixed-length fields. And good
reasons for checksums.)

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Stephen Farrell
Sent: Tue 2009-02-17 18:35
To: DTN
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv
=20

Folks,

We've got our first "last call" victim:-)

Wes reckons that the SDNV draft [1] is ready to become
an informational RFC.

Can you read and comment on this in the next month, i.e.
before the end of March 17th.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

PS: I've at least one comment - some references are now
out of date:-)

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------_=_NextPart_001_01C9913B.868C1C79
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>The SDNV draft needs to warn about use of SDNVs in =
protocol headers<BR>
which are not protected by checksums, where an error flipping the<BR>
last bit of a byte turns one SDNV into two, or two into one, and<BR>
completely breaks parsing of a complex protocol format built<BR>
out of sequential SDNVs, as every SDNV is now misplaced in sequence.<BR>
<BR>
Use of SDNVs in protocol headers - especially protocol<BR>
headers not protected by some form of reliability check thanks to<BR>
the benefits of mutable canonicalisation - needs to be<BR>
discouraged. Use of protocols dependent on SDNVs<BR>
without reliability checks ensuring robustness of SDNVs needs<BR>
to be strongly discouraged for this reason.<BR>
<BR>
(There are good reasons for fixed-length fields. And good<BR>
reasons for checksums.)<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Stephen Farrell<BR>
Sent: Tue 2009-02-17 18:35<BR>
To: DTN<BR>
Subject: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-sdnv<BR>
<BR>
<BR>
Folks,<BR>
<BR>
We've got our first &quot;last call&quot; victim:-)<BR>
<BR>
Wes reckons that the SDNV draft [1] is ready to become<BR>
an informational RFC.<BR>
<BR>
Can you read and comment on this in the next month, i.e.<BR>
before the end of March 17th.<BR>
<BR>
Please bear in mind that as an IRTF RG, and not an<BR>
IETF WG, we do not need to establish rough consensus<BR>
for documents, but if we do have that its a good thing.<BR>
For the later stages of review, it's useful if folks have<BR>
said &quot;I agree, its ok and its ready&quot; or equivalent so<BR>
please do send a mail to the list saying that if it<BR>
applies. (Preserving the subject line so we can just<BR>
add a link in the tracker later.)<BR>
<BR>
Thanks,<BR>
Stephen.<BR>
<BR>
PS: I've at least one comment - some references are now<BR>
out of date:-)<BR>
<BR>
[1] <A =
HREF=3D"http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv">http://tools.ie=
tf.org/html/draft-irtf-dtnrg-sdnv</A><BR>
<BR>
<BR>
_______________________________________________<BR>
dtn-interest mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9913B.868C1C79--

From: Marshall Eubanks <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Tue, 17 Feb 2009 13:55:03 -0500
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

Is the newest boilerplate in use ?

Regards
Marshall

On Feb 17, 2009, at 1:35 PM, Stephen Farrell wrote:

>
> Folks,
>
> We've got our first "last call" victim:-)
>
> Wes reckons that the SDNV draft [1] is ready to become
> an informational RFC.
>
> Can you read and comment on this in the next month, i.e.
> before the end of March 17th.
>
> Please bear in mind that as an IRTF RG, and not an
> IETF WG, we do not need to establish rough consensus
> for documents, but if we do have that its a good thing.
> For the later stages of review, it's useful if folks have
> said "I agree, its ok and its ready" or equivalent so
> please do send a mail to the list saying that if it
> applies. (Preserving the subject line so we can just
> add a link in the tracker later.)
>
> Thanks,
> Stephen.
>
> PS: I've at least one comment - some references are now
> out of date:-)
>
> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 17 Feb 2009 18:50:16 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Hidden Minneapolis meeting minutes?

I've asked. We'll see.
S.

Lloyd Wood wrote:
> The Minneapolis DTNRG meeting slides at:
> http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html
> are not linked to directly from the main meeting proceedings page and frameset:
> http://www.ietf.org/proceedings/08nov/
> possibly because meeting minutes aren't included?
> 
> The slides are a little difficult to find. Can this be corrected?
> 
> thanks,
> 
> L.
> 
> Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 17 Feb 2009 18:35:06 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-sdnv

Folks,

We've got our first "last call" victim:-)

Wes reckons that the SDNV draft [1] is ready to become
an informational RFC.

Can you read and comment on this in the next month, i.e.
before the end of March 17th.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

PS: I've at least one comment - some references are now
out of date:-)

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv

From: Kevin Fall <[email-masked]>
To: "Parikh, Salil" <[email-masked]>
Date: Mon, 16 Feb 2009 20:14:19 -0800
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

--Apple-Mail-17-986305961
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

We discussed this type of thing in the 2007 HotNets paper (where it =20
was called "obsoletes").  In principal, it makes sense.  Aside from =20
looking at an API, that paper discusses that there might be different =20=

sorts of 'obsoletes'... some are in sequence space, some are in =20
timestamp space, and some are version vectors.  A quick read through =20
this suggests to me that it only deals with timestamps.  Is that right?

- K

On Feb 11, 2009, at Feb 114:04 PMPST, Parikh, Salil wrote:

> Not that this is a new idea...
>
> See Section 3.2.12 of =
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-12.txt
>
> And: Section 6.14 of =
http://www.eyrie.org/~eagle/usefor/other/son-of-1036
>
>
> From: [email-masked] =
[mailto:[email-masked]=20
> ] On Behalf Of Parikh, Salil
> Sent: Wednesday, January 07, 2009 10:30 AM
> To: [email-masked]
> Subject: [dtn-interest] I-D: Delay-Tolerant Networking Superseding =20
> Bundle Extension Block
>
> Hello,
>
> We have submitted an Internet-Draft titled =93Delay-Tolerant =20
> Networking Superseding Bundle Extension Block=94.  We welcome review =20=

> and comment from the DTNRG community.
>
> =
http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extens=
ion-block-00.txt
>
> Abstract:
>
> This document defines an optional Bundle Protocol block called the =20
> Superseding Bundle Extension Block (SBEB) for use with the Bundle =20
> Protocol in the context of the Delay-Tolerant Networking =20
> Architecture.  Applications use this block to call for the removal =20
> of previously sent bundles that are rendered obsolete by more recent =20=

> bundles. Upon receiving a bundle with an SBEB, a node will search =20
> its bundle store (and outbound queues) for bundles that are =20
> obsoleted by other related bundles according to their source and =20
> destination EID, and the SBEB cookie (if present), and may delete =20
> some or all of them. Discarding obsolete bundles helps conserve =20
> storage space and prevents expending resources in further forwarding =20=

> bundles that are no longer relevant.  The bundle protocol already =20
> uses expiration times to remove bundles that are no longer useful to =20=

> applications.  The SBEB is a way for applications to mark bundles =20
> that a node may delete prior to their expiration times.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-17-986305961
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">We discussed this type of thing =
in the 2007 HotNets paper (where it was called "obsoletes"). &nbsp;In =
principal, it makes sense. &nbsp;Aside from looking at an API, that =
paper discusses that there might be different sorts of 'obsoletes'... =
some are in sequence space, some are in timestamp space, and some are =
version vectors. &nbsp;A quick read through this suggests to me that it =
only deals with timestamps. &nbsp;Is that right?<div><br></div><div>- =
K</div><div><br></div><div><br><div><div><div>On Feb 11, 2009, at Feb =
114:04 PMPST, Parikh, Salil wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><span style=3D"color: rgb(31, =
73, 125); ">Not that this is a new idea...<o:p></o:p></span></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif; "><span style=3D"color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><span style=3D"color: rgb(31, =
73, 125); ">See Section 3.2.12 of<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-12.tx=
t" style=3D"color: blue; text-decoration: underline; =
">http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-12.txt</a><=
o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif; "><span style=3D"color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><span style=3D"color: rgb(31, =
73, 125); ">And: Section 6.14 of<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"http://www.eyrie.org/~eagle/usefor/other/son-of-1036" =
style=3D"color: blue; text-decoration: underline; =
">http://www.eyrie.org/~eagle/usefor/other/son-of-1036</a><o:p></o:p></spa=
n></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-left: =
0in; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif; "><span style=3D"color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><span style=3D"color: rgb(31, =
73, 125); "><o:p>&nbsp;</o:p></span></div><div><div =
style=3D"border-right-style: none; border-bottom-style: none; =
border-left-style: none; border-width: initial; border-color: initial; =
border-top-style: solid; border-top-color: rgb(181, 196, 223); =
border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; =
padding-bottom: 0in; padding-left: 0in; "><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><b><span style=3D"font-size: =
10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span =
style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; "><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" =
style=3D"color: blue; text-decoration: underline; =
">[email-masked]</a><span =
class=3D"Apple-converted-space">&nbsp;</span>[<a =
href=3D"mailto:[email-masked]" =
style=3D"color: blue; text-decoration: underline; =
">mailto:[email-masked]</a>]<span =
class=3D"Apple-converted-space">&nbsp;</span><b>On Behalf Of<span =
class=3D"Apple-converted-space">&nbsp;</span></b>Parikh, =
Salil<br><b>Sent:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Wednesday, January 07, 2009 =
10:30 AM<br><b>To:</b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: =
blue; text-decoration: underline; =
">[email-masked]</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>[dtn-interest] I-D: =
Delay-Tolerant Networking Superseding Bundle Extension =
Block<o:p></o:p></span></div></div></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif; ">Hello,<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif; ">We have submitted an Internet-Draft titled =93Delay-Tolerant=
 Networking Superseding Bundle Extension Block=94.&nbsp; We welcome =
review and comment from the DTNRG community.<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif; "><o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><a =
href=3D"http://www.ietf.org/internet-drafts/draft-parikh-bundle-supersedin=
g-extension-block-00.txt" style=3D"color: blue; text-decoration: =
underline; =
">http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-exte=
nsion-block-00.txt</a><o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif; ">Abstract:<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif; ">This document defines an optional Bundle Protocol block =
called the Superseding Bundle Extension Block (SBEB) for use with the =
Bundle Protocol in the context of the Delay-Tolerant Networking =
Architecture.&nbsp; Applications use this block to call for the removal =
of previously sent bundles that are rendered obsolete by more recent =
bundles. Upon receiving a bundle with an SBEB, a node will search its =
bundle store (and outbound queues) for bundles that are obsoleted by =
other related bundles according to their source and destination EID, and =
the SBEB cookie (if present), and may delete some or all of them. =
Discarding obsolete bundles helps conserve storage space and prevents =
expending resources in further forwarding bundles that are no longer =
relevant.&nbsp; The bundle protocol already uses expiration times to =
remove bundles that are no longer useful to applications.&nbsp; The SBEB =
is a way for applications to mark bundles that a node may delete prior =
to their expiration =
times.<o:p></o:p></div></div>_____________________________________________=
__<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]" style=3D"color: =
blue; text-decoration: underline; =
">[email-masked]</a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
 style=3D"color: blue; text-decoration: underline; =
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br=
></div></span></blockquote></div><br></div></div></body></html>=

--Apple-Mail-17-986305961--

From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 16 Feb 2009 19:12:31 +0000
Cc: DTN <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Coming to San Francisco? Your name here...

On 16 Feb 2009, at 14:57, Stephen Farrell wrote:
> Just to clarify. This is only for the 2 day DTNRG meeting
> being hosted by Google on March 19/20

Is there an agenda?

(Bit hard to justify international travel to a meeting without one...)

thanks,

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Date: Mon, 16 Feb 2009 17:34:04 +0000
To: [email-masked]
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] Hidden Minneapolis meeting minutes?

The Minneapolis DTNRG meeting slides at:
http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html
are not linked to directly from the main meeting proceedings page and frameset:
http://www.ietf.org/proceedings/08nov/
possibly because meeting minutes aren't included?

The slides are a little difficult to find. Can this be corrected?

thanks,

L.

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 

Date: Mon, 16 Feb 2009 14:57:29 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Coming to San Francisco? Your name here...

Just to clarify. This is only for the 2 day DTNRG meeting
being hosted by Google on March 19/20

For the slot at the IETF, just turn up if you like.
Sorry for the ambiguity,
Stephen.

Content-class: urn:content-classes:message
Date: Mon, 16 Feb 2009 14:33:07 -0000
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99043.7BBFA4FD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,=20

As DTN support many different naming conventions, but all names should =
be unique for communication to occur without errors. So,
1. To what extent it is correct that source will know the destination =
endpoint Id ...

The other question is:=20
   "The problem is that current IBC schemes effectively
   act only as a kind of "group certificate" where all of the nodes
   using a given private key generator can use a single "certificate",   =

   but the problem of validity for that "certificate" (which will
   contain the generator's parameters) is the same problem as verifying
   a CA certificate in a standard PKI"

1. To what extent we need the certificates, If above naming convention =
is true ..=20

I know it is generic, but please comment your thoughts it will help to =
dig into problem,=20

thanks,

regards,
Nasir

------_=_NextPart_001_01C99043.7BBFA4FD
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE></TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi,<BR>
<BR>
As DTN support many different naming conventions, but all names should =
be unique for communication to occur without errors. So,<BR>
1. To what extent it is correct that source will know the destination =
endpoint Id ...<BR>
<BR>
The other question is:<BR>
&nbsp;&nbsp; &quot;The problem is that current IBC schemes =
effectively<BR>
&nbsp;&nbsp; act only as a kind of &quot;group certificate&quot; where =
all of the nodes<BR>
&nbsp;&nbsp; using a given private key generator can use a single =
&quot;certificate&quot;,&nbsp;&nbsp;<BR>
&nbsp;&nbsp; but the problem of validity for that =
&quot;certificate&quot; (which will<BR>
&nbsp;&nbsp; contain the generator's parameters) is the same problem as =
verifying<BR>
&nbsp;&nbsp; a CA certificate in a standard PKI&quot;<BR>
<BR>
1. To what extent we need the certificates, If above naming convention =
is true ..<BR>
<BR>
I know it is generic, but please comment your thoughts it will help to =
dig into problem,<BR>
<BR>
thanks,<BR>
<BR>
regards,<BR>
Nasir</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C99043.7BBFA4FD--

Date: Mon, 16 Feb 2009 14:27:57 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Coming to San Francisco? Your name here...

--------------040102080102050907010003
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Folks,

Here's the list of those I currently have for attending
our meeting next month.

Please send corrections (offlist I guess) asap,
Thanks,
Stephen.

--------------040102080102050907010003
Content-Type: text/plain; name="alist.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="alist.txt"

As of 20090216 
 
Plan to attend 
 
 1. Stephen Farrell
 2. Kevin Fall
 3. Joerg Ott
 4. Chris Small
 5. Scott Burleigh
 6. Susan Symmington
 7. Alex McMahon
 8. Lloyd Wood
 9.  Will Ivancic
10. Joe Macker
11. Laveen Sundararaj
12. Avri Doria
13. Jim Snyder
14. Adrian Hooke
15. Elwyn Davies
16. Marc Blanchet
17. Simon Perreault
18. Ignacio Solis
19. Hans Kruse
20. Matt Bromage
21. Lofti Benmohamed
22. Preston Marshall
23. Marshall Eubanks
24. Pete Lovell
 
(Folks who travel in crowds
 
25-28: 4 "other BBN'ers" 
29-31: 3 of Jim Synder's service partners in the US army
 
Would like to
 
32. Bob Durst
33. Shawn Ostermann
34. Andrew Sullivan

--------------040102080102050907010003--

Date: Mon, 16 Feb 2009 14:08:55 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] [Fwd: 74th IETF - DRAFT Agenda]

--------------000707050509040701080908
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

FYI. DTNRG currently scheduled for Tuesday. It can change.

Stephen.

--------------000707050509040701080908
Content-Type: message/rfc822; name="74th IETF - DRAFT Agenda.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="74th IETF - DRAFT Agenda.eml"

From: IETF Agenda <[email-masked]>
To: Working Group Chairs <[email-masked]>
Subject: 74th IETF - DRAFT Agenda 
Date: Fri, 13 Feb 2009 17:45:27 -0800 (PST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The Draft agenda can now be viewed at:
https://datatracker.ietf.org/meeting/74/agenda.html

Please note that the confirmation message you received may not reflect
the correct session length.  All efforts were made to schedule the groups
without any conflicts but unfortunately that was unavoidable.

The cutoff date for requests to reschedule Working Group and BOF meetings
is Wednesday, February 25, 2009 at 17:00 PST (01:00 Thursday, February 26
UTC/GMT).  Please send you requests to: [email-masked].

Online registration for the IETF meeting is at:
http://www.ietf.org/meetings/74/

Only 36 days until the San Francisco IETF! 

--------------000707050509040701080908--

Date: Mon, 16 Feb 2009 14:07:46 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] RG "last calls"

Hi all,

In Minneapolis we noted that we've a lot of documents
and that we should finish those that are done.

As soon as the authors of any of those listed below send
me a mail saying "we're ready," I'll start a one month
"last call" on them. There'll be a separate thread for
each, so hold any last-call type comments until you
see that thread started.

As a reminder Elwyn Davies has kindly agreed to shepherd
a bunch of these together, so we should aim to have
that bunch entering the IRSG review process just after
our next meeting.

Note that in contrast to an IETF WG, for an IRTF RG,
there is no requirement that we achieve "rough
consensus" - its ok for research groups to publish
documents where there is no consensus, so long as
that's clear from the document and all the other
requirements/reviews get done. However, if we do
have rough consensus or better on documents, that's
clearly a plus. So if you see a last-call going by
for a document you do think is ready, please say
so explicitly.

Thanks,
Stephen.

draft-irtf-dtnrg-prophet
draft-irtf-dtnrg-tcp-clayer
draft-irtf-dtnrg-bundle-security
draft-irtf-dtnrg-sec-overview
draft-irtf-dtnrg-sdnv
draft-irtf-dtnrg-bundle-previous-hop-block
draft-irtf-dtnrg-cbhe

Date: Mon, 16 Feb 2009 14:01:26 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Belated Minneapolis meeting notes

--------------060207030608080506010205
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hi All,

Due to a bit of a lost-file problem between Kevin and I,
I've only now gotten together the meeting notes from last
November. But here they are in any case. I guess just mail
the list if there're any corrections.

Thanks to Elwyn for providing raw notes (he did that in
a timely fashion, the delay is the chairs' fault;-)

Stephen.

PS: I'll follow up separately wrt "last calls" and
logistics for next month.

--------------060207030608080506010205
Content-Type: application/msword; name="Meeting notes.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="Meeting notes.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAagAAAAAA
AAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
--------------060207030608080506010205
Content-Type: application/pdf; name="Meeting notes.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="Meeting notes.pdf"

--------------060207030608080506010205--

From: "Burleigh, Scott C" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Fri, 13 Feb 2009 13:55:51 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  Hierarchy

> -----Original Message-----
> From: Prithwish Basu [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2009 11:04 PM
> To: Burleigh, Scott C
> Cc: dtn interest
> Subject: Re: [dtn-interest] Re(2): Hierarchy
> 
> Hi Scott,
> 
> We had a paper in Milcom last year about some aspects of the late
> binding problem. Here's a pointer:
> 
> http://www.ir.bbn.com/~pbasu/pubs/milcom08.pdf
> 
> The network of name knowledge bases (hosted at progressive resolvers)
> mentioned in the paper can be used to achieve something like this.  A
> NameKB hosted at each node can have arbitrarily complex transformation
> rules which take in the immutable name (or name query in case of anycast
> style names) and output the "canonical DTN name" of a resolver node
> potentially after a series of transformations (these rules may be
> chained).
> 
> Also, the metadata extension block was used to carry hint information
> stamped by intermediate resolvers. Obviously, the scalability problem
> caused by a combination of non-aggregatable namespaces and arbitrary
> disruption patterns is the hardest one to solve here (if not impossible)
> but for statically configured and predictable scenarios and also for
> mobile scenarios with available geographic information, it is more
> tractable, I think.

You're right, Prithwish, I think this is a generalization of the same basic concept.  The one place where I think we can get some leverage that you may not be looking at (I'm not sure; I need to read more about your system) is in taking the "canonical DTN name of a resolver node" -- which I take to be a late-bound proximate destination -- and checking it against a routing table whose entries may in some cases be wild-carded canonical DTN names.  Which I think gives you aggregation that helps to solve the scalability problem.

Scott

From: "Burleigh, Scott C" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 13 Feb 2009 12:06:04 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2): Hierarchy

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

Responding to both of these postings at once:

I certainly agree that a distributed database that spans episodic interplan=
etary links will be non-coherent for longer periods of time than a distribu=
ted database that lives in the Internet, and if this incoherence results in=
 an unacceptable level of routing error then the approach won't work.  I th=
ink it's difficult to know at this point whether or not this will be the ca=
se, though.  I can imagine scenarios in which these kinds of mapping relati=
onships change so rarely that the length of time required to change them on=
 all copies of the database doesn't limit their usefulness.  It's the sort =
of question that I think merits some careful engineering study.

And I'm perfectly comfortable with using a different syntactic structure fo=
r routing table entries, if that makes more sense.  I'm not sure I understa=
nd the threat, and I'm not clear on how one would "not allow" partial-strin=
g-match wild-carding in private, local routing tables, but I don't have str=
ong feelings on this topic one way or the other.

Scott

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Ivancic, William D. (G=
RC-RHN0)
Sent: Friday, February 13, 2009 7:50 AM
To: Gerardo Izquierdo; [email-masked]
Subject: Re: [dtn-interest] Re(2): Hierarchy

I suspect disrupted (disconnected)  databases are relatively difficult to s=
ynchronize compared to connected databases - particularly over long distanc=
es.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

________________________________
From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Gerardo Izquierdo
Sent: Friday, February 13, 2009 5:51 AM
To: [email-masked]
Subject: Re: [dtn-interest] Re(2): Hierarchy
Hi Scott

Just a formal question.

For example, the destination of the bundle is p_smith.dtn but the first rou=
ter it hits has never heard of p_smith.dtn.  However that router does know =
how to forward bundles to people based on where they work, so it looks up "=
p_smith" in its Where They Work database and gets Yoyodyne.dtn.  Now it loo=
ks for Yoyodyne.dtn its routing table, encounters the *dyne.dtn entry, and =
forwards the bundle to the node associated with that entry for further forw=
arding.

It isn't a security issue having name routing in the "*dyne.dtn" format?
People could not be aware of a "*dyne.dtn" rule somewhere in the network wh=
en they register "Yoyodyne.dtn". I think instead it could be better not all=
owing this kind of routing, but "*.dyne.dtn" and then I register "Yoyo" und=
er "dyne.dtn" giving "Yoyo.dybe.dtn"

btw I find very interesting this approach (is similar to the actual transfo=
rmation of a phone number in an EMEI) but I'm concerned with the distribute=
d database involved here, and the update of the information with thousands =
of dtn domains.

Best regards
Gerardo.

--_000_FD514C8A5155C64C9B145B48D674EF54494DA6746DALTPHYEMBEVSP_
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:m=3D"http://schemas.microsoft.com/office/2004/12/omml" 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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @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
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Responding to both of these postings at once:<o:p></o:p></sp=
an></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'>I certainly agree that a distributed database that spans epi=
sodic
interplanetary links will be non-coherent for longer periods of time than a
distributed database that lives in the Internet, and if this incoherence
results in an unacceptable level of routing error then the approach won&#82=
17;t
work.&nbsp; I think it&#8217;s difficult to know at this point whether or n=
ot
this will be the case, though.&nbsp; I can imagine scenarios in which these
kinds of mapping relationships change so rarely that the length of time
required to change them on all copies of the database doesn&#8217;t limit t=
heir
usefulness.&nbsp; It&#8217;s the sort of question that I think merits some
careful engineering study.<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'>And I&#8217;m perfectly comfortable with using a different
syntactic structure for routing table entries, if that makes more sense.&nb=
sp;
I&#8217;m not sure I understand the threat, and I&#8217;m not clear on how =
one
would &#8220;not allow&#8221; partial-string-match wild-carding in private,
local routing tables, but I don&#8217;t have strong feelings on this topic =
one
way or the other.<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'>Scott<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>

<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"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Ivancic,
William D. (GRC-RHN0)<br>
<b>Sent:</b> Friday, February 13, 2009 7:50 AM<br>
<b>To:</b> Gerardo Izquierdo; [email-masked]<br>
<b>Subject:</b> Re: [dtn-interest] Re(2): Hierarchy<o:p></o:p></span></p>

</div>

</div>

<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";
color:blue'>I suspect disrupted (disconnected) &nbsp;databases are relative=
ly
difficult to synchronize compared to connected databases - particularly ove=
r
long distances.</span><o:p></o:p></p>

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

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

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:blue'>Will</span><o:p></o:p></p>

<div>

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

</div>

<p><span style=3D'font-size:10.0pt'>******************************<br>
William D. Ivancic<br>
Phone 216-433-3494<br>
Fax 216-433-8705<br>
Networking Lab 216-433-2620<br>
DTN Lab 216-433-2981<br>
Mobile 440-503-4892<br>
<a href=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/=
~ivancic</a></span><o:p></o:p></p>

<div>

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

</div>

<blockquote style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0=
in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><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"'> [email-masked]=
search.net
[mailto:[email-masked]] <b>On Behalf Of =
</b>Gerardo
Izquierdo<br>
<b>Sent:</b> Friday, February 13, 2009 5:51 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Re: [dtn-interest] Re(2): Hierarchy</span><o:p></o:p></p>

<div>

<p class=3DMsoNormal>Hi Scott<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Just a formal question.<o:p></o:p></p>

</div>

<blockquote style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

<div>

<p class=3DMsoNormal><br>
For example, the destination of the bundle is p_smith.dtn but the first rou=
ter
it hits has never heard of p_smith.dtn.&nbsp;&nbsp;However that router does
know how to forward bundles to people based on where they work, so it looks=
 up
&quot;p_smith&quot; in its Where They Work database and gets
Yoyodyne.dtn.&nbsp;&nbsp;Now it looks for Yoyodyne.dtn its routing table,
encounters the *dyne.dtn entry, and forwards the bundle to the node associa=
ted
with that entry for further forwarding.<br>
&nbsp;<o:p></o:p></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal>It isn't a security issue having name routing in the
&quot;*dyne.dtn&quot; format? <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>People could not be aware of a &quot;*dyne.dtn&quot; r=
ule
somewhere in the network when they register &quot;Yoyodyne.dtn&quot;. I thi=
nk
instead it could be better not allowing this kind of routing, but
&quot;*.dyne.dtn&quot; and then I register &quot;Yoyo&quot; under
&quot;dyne.dtn&quot; giving &quot;Yoyo.dybe.dtn&quot;<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>btw I find very interesting this approach (is similar =
to the
actual transformation of a phone number in an EMEI) but I'm concerned with =
the
distributed database involved here, and the update of the information with
thousands of dtn domains.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Best regards<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>Gerardo.<o:p></o:p></p>

</div>

</blockquote>

</div>

</div>

</body>

</html>

--_000_FD514C8A5155C64C9B145B48D674EF54494DA6746DALTPHYEMBEVSP_--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Gerardo Izquierdo <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 13 Feb 2009 09:49:34 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2): Hierarchy

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

I suspect disrupted (disconnected)  databases are relatively difficult to s=
ynchronize compared to connected databases - particularly over long distanc=
es.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

________________________________
From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Gerardo Izquierdo
Sent: Friday, February 13, 2009 5:51 AM
To: [email-masked]
Subject: Re: [dtn-interest] Re(2): Hierarchy

Hi Scott

Just a formal question.

For example, the destination of the bundle is p_smith.dtn but the first rou=
ter it hits has never heard of p_smith.dtn.  However that router does know =
how to forward bundles to people based on where they work, so it looks up "=
p_smith" in its Where They Work database and gets Yoyodyne.dtn.  Now it loo=
ks for Yoyodyne.dtn its routing table, encounters the *dyne.dtn entry, and =
forwards the bundle to the node associated with that entry for further forw=
arding.

It isn't a security issue having name routing in the "*dyne.dtn" format?
People could not be aware of a "*dyne.dtn" rule somewhere in the network wh=
en they register "Yoyodyne.dtn". I think instead it could be better not all=
owing this kind of routing, but "*.dyne.dtn" and then I register "Yoyo" und=
er "dyne.dtn" giving "Yoyo.dybe.dtn"

btw I find very interesting this approach (is similar to the actual transfo=
rmation of a phone number in an EMEI) but I'm concerned with the distribute=
d database involved here, and the update of the information with thousands =
of dtn domains.

Best regards
Gerardo.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16809" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D437124815-13022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>I suspect disrupted (disconnected) &nbsp;databases=
 are=20
relatively difficult to synchronize compared to connected databases -=20
particularly over long distances.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D437124815-13022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D437124815-13022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D437124815-13022009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Will</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV><!-- Converted from text/plain format -->
<P><FONT size=3D2>******************************<BR>William D. Ivancic<BR>P=
hone=20
216-433-3494<BR>Fax 216-433-8705<BR>Networking Lab 216-433-2620<BR>DTN Lab=
=20
216-433-2981<BR>Mobile 440-503-4892<BR><A=20
href=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/~iv=
ancic</A><BR></FONT></P>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli=
d; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B>=20
  [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf O=
f=20
  </B>Gerardo Izquierdo<BR><B>Sent:</B> Friday, February 13, 2009 5:51=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Re:=20
  [dtn-interest] Re(2): Hierarchy<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>Hi Scott</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Just a formal question.</DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV><BR>For example, the destination of the bundle is p_smith.dtn but =
the=20
    first router it hits has never heard of p_smith.dtn.&nbsp;&nbsp;However=
 that=20
    router does know how to forward bundles to people based on where they w=
ork,=20
    so it looks up "p_smith" in its Where They Work database and gets=20
    Yoyodyne.dtn.&nbsp;&nbsp;Now it looks for Yoyodyne.dtn its routing tabl=
e,=20
    encounters the *dyne.dtn entry, and forwards the bundle to the node=20
    associated with that entry for further=20
forwarding.<BR>&nbsp;</DIV></BLOCKQUOTE>
  <DIV dir=3Dltr>It isn't a security issue having name routing in the "*dyn=
e.dtn"=20
  format? </DIV>
  <DIV dir=3Dltr>People could not be aware of a "*dyne.dtn" rule somewhere =
in the=20
  network when they register "Yoyodyne.dtn". I think instead it could be be=
tter=20
  not allowing this kind of routing, but "*.dyne.dtn" and then I register "=
Yoyo"=20
  under "dyne.dtn" giving "Yoyo.dybe.dtn"</DIV>
  <DIV dir=3Dltr>&nbsp;</DIV>
  <DIV dir=3Dltr>btw I find very interesting this approach (is similar to t=
he=20
  actual transformation of a phone number in an EMEI) but I'm concerned wit=
h the=20
  distributed database involved here, and the update of the information wit=
h=20
  thousands of dtn domains.</DIV>
  <DIV dir=3Dltr>&nbsp;</DIV>
  <DIV dir=3Dltr>Best regards</DIV>
  <DIV dir=3Dltr>Gerardo.</DIV></BLOCKQUOTE></BODY></HTML>

--_000_3A5AA67A8B120B48825BFFCF544385613EC03EA3NDJSSCC03ndcnas_--

Date: Fri, 13 Feb 2009 11:50:38 +0100
From: Gerardo Izquierdo <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Re(2): Hierarchy

--0016364d1fef85b01e0462ca9b41
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Scott

Just a formal question.

For example, the destination of the bundle is p_smith.dtn but the first
router it hits has never heard of p_smith.dtn.  However that router does
know how to forward bundles to people based on where they work, so it looks
up "p_smith" in its Where They Work database and gets Yoyodyne.dtn.  Now it
looks for Yoyodyne.dtn its routing table, encounters the *dyne.dtn entry,
and forwards the bundle to the node associated with that entry for further
forwarding.

It isn't a security issue having name routing in the "*dyne.dtn" format?
People could not be aware of a "*dyne.dtn" rule somewhere in the network
when they register "Yoyodyne.dtn". I think instead it could be better not
allowing this kind of routing, but "*.dyne.dtn" and then I register "Yoyo"
under "dyne.dtn" giving "Yoyo.dybe.dtn"

btw I find very interesting this approach (is similar to the actual
transformation of a phone number in an EMEI) but I'm concerned with the
distributed database involved here, and the update of the information with
thousands of dtn domains.

Best regards
Gerardo.

--0016364d1fef85b01e0462ca9b41
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Hi Scott</div>
<div>&nbsp;</div>
<div>Just a formal question.</div>
<blockquote dir=3D"ltr" style=3D"MARGIN-RIGHT: 0px">
<div><br>For example, the destination of the bundle is p_smith.dtn but the =
first router it hits has never heard of p_smith.dtn.&nbsp;&nbsp;However tha=
t router does know how to forward bundles to people based on where they wor=
k, so it looks up &quot;p_smith&quot; in its Where They Work database and g=
ets Yoyodyne.dtn.&nbsp;&nbsp;Now it looks for Yoyodyne.dtn its routing tabl=
e, encounters the *dyne.dtn entry, and forwards the bundle to the node asso=
ciated with that entry for further forwarding.<br>
&nbsp;</div></blockquote>
<div dir=3D"ltr">It isn&#39;t a security issue having name routing in the &=
quot;*dyne.dtn&quot; format? </div>
<div dir=3D"ltr">People could not be aware of a &quot;*dyne.dtn&quot; rule =
somewhere in the network when they register &quot;Yoyodyne.dtn&quot;. I thi=
nk instead it could be better not allowing this kind of routing, but &quot;=
*.dyne.dtn&quot; and then I register &quot;Yoyo&quot; under &quot;dyne.dtn&=
quot; giving &quot;Yoyo.dybe.dtn&quot;</div>

<div dir=3D"ltr">&nbsp;</div>
<div dir=3D"ltr">btw I find very interesting this approach (is similar to t=
he actual transformation of a phone number in an EMEI) but I&#39;m concerne=
d with the distributed database involved here, and the update of the inform=
ation with thousands of dtn domains.</div>

<div dir=3D"ltr">&nbsp;</div>
<div dir=3D"ltr">Best regards</div>
<div dir=3D"ltr">Gerardo.</div>

--0016364d1fef85b01e0462ca9b41--

From: Peter Lovell <[email-masked]>
To: Susan <[email-masked]>, dtn interest <[email-masked]>
Date: Thu, 12 Feb 2009 15:05:43 -0500
Subject: Re: [dtn-interest] FW: DTN bundle diversion and encapsulatin I-Ds

Hi Susan,

I did read them (encapsulation more than diversion, I'll admit) and need
to reread again.

Thanks.....Peter

On Thu, Feb 12, 2009, Symington, Susan F. <[email-masked]> wrote:

>Hello DTNRG,
>
>Has anyone had a chance to read through the DTN Bundle Diversion I-D
>(http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-
>divert-00.txt) and the revised DTN Bundle-in-Bundle Encapsulation I-D
>(http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-
>encapsulation-05.txt) that we submitted earlier this month? We are
>interested in hearing feedback on these drafts. What do folks think?
>
>The drafts are intended to address concerns that were raised to a
>previous version of the Bundle-in-Bundle Encapsulation I-D.  The Bundle
>Diversion I-D was created to define a general capability to divert a
>bundle from the forwarding chain for processing by an application agent,
>with one particular use case being diversion of a bundle to an
>application agent that performs encapsulation.  The Bundle-in-Bundle
>Encapsulation I-D now just defines the encapsulation format.
>
>Here is the abstract from the DTN Bundle Diversion I-D:
>Abstract
>
>This document defines two extensions to the capabilities of a Bundle
>Protocol Agent (BPA) (as defined in [refs.DTNBP]) that is processing
>bundles within the context of a Delay-Tolerant Network architecture
> [refs.DTNarch].  It defines an operation called "diversion", which is
>the act of a bundle protocol agent moving an entire bundle from some
>point in bundle processing in the BPA to a DTN application agent.
>This diversion of a bundle from the BPA to an application agent is
>distinct from delivery of the bundle at that application agent.  This
>document defines a second operation, called "injection", which is the
>inverse of diversion.  Injection is the act of an application agent
>moving an entire bundle from the application agent into some point in
>bundle processing in the BPA.  This injection of a bundle from an
>application agent to the BPA is distinct from bundle transmission.
>
>Bundle diversion is expected to be of general utility in DTN in
>instances in which all or part of a bundle needs to be transcoded while
>the bundle is being forwarded through the network. A bundle that is
>received at a BPA in one coding format can be diverted to an application
>agent that has as its purpose the conversion of the bundle to an
>alternate coding format. After transcoding, an application agent can
>inject a transcoded bundle back into BPA processing to be forwarded or
>delivered in its new format. Bundle-in-bundle encapsulation is a
>specific example of a use case that has been identified for bundle
>diversion. In order to perform encapsulation, bundle diversion is
>required to move the bundle to be encapsulated from BPA processing to
>the encapsulating application agent at the start of the tunnel, and
>bundle injection is required to move the de-encapsulated bundle from the
>de-encapsulating application agent back into BPA bundle processing at
>the end of the tunnel.
>
>We are interested in hearing your feedback. Thanks.
>
>-susan
>
>*****************************************************************
>Susan Symington
>The MITRE Corporation
>[email-masked]
>703-983-7209 (voice)
>703-983-7142 (fax)
>******************************************************************
>From: Symington, Susan F.
>Sent: Monday, February 02, 2009 3:26 PM
>To: dtn interest
>Subject: DTN bundle diversion and encapsulatin I-Ds
>
>DTN RG:
>
>I just submitted two DTN I-Ds that are related to each other, DTN Bundle
>Diversion (draft-irtf-dtnrg-bundle-divert-00) and DTN Bundle-in-Bundle
>Encapsulation (draft-irtf-dtnrg-bundle-encapsulation-05).
>
>As I discussed at the Minneapolis meeting, the Bundle Diversion draft
>enhances RFC 5050 by introducing two new concepts: bundle diversion and
>bundle injection. "Diversion" is the act of a bundle protocol agent
>moving an entire bundle from some point in bundle processing in the BPA
>to a DTN application agent. This diversion of a bundle from the BPA to
>an application agent is distinct from delivery of the bundle at that
>application agent.  "Injection" is the inverse of diversion. It is the
>act of an application agent moving an entire bundle from the application
>agent into some point in bundle processing in the BPA.  This injection
>of a bundle from an application agent to the BPA is distinct from bundle
>transmission. Diversion might take place, for example, at the entrance
>to an encapsulation tunnel and injection might take place at the other
>end of that tunnel.
>
>The Bundle-in-Bundle Encapsulation I-D now just defines the capability
>and format for placing one or more bundles inside of the payload field
>of an encapsulating bundle's Bundle Payload Block.
>
>-susan
>*****************************************************************
>Susan Symington
>The MITRE Corporation
>[email-masked]
>703-983-7209 (voice)
>703-983-7142 (fax)
>******************************************************************
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Symington, Susan F." <[email-masked]>
To: dtn interest <[email-masked]>
Date: Thu, 12 Feb 2009 14:17:37 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] FW: DTN bundle diversion and encapsulatin I-Ds

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

Hello DTNRG,

Has anyone had a chance to read through the DTN Bundle Diversion I-D (http:=
//www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-divert-00.txt) and t=
he revised DTN Bundle-in-Bundle Encapsulation I-D (http://www.ietf.org/inte=
rnet-drafts/draft-irtf-dtnrg-bundle-encapsulation-05.txt) that we submitted=
 earlier this month? We are interested in hearing feedback on these drafts.=
 What do folks think?

The drafts are intended to address concerns that were raised to a previous =
version of the Bundle-in-Bundle Encapsulation I-D.  The Bundle Diversion I-=
D was created to define a general capability to divert a bundle from the fo=
rwarding chain for processing by an application agent, with one particular =
use case being diversion of a bundle to an application agent that performs =
encapsulation.  The Bundle-in-Bundle Encapsulation I-D now just defines the=
 encapsulation format.

Here is the abstract from the DTN Bundle Diversion I-D:
Abstract

This document defines two extensions to the capabilities of a Bundle
Protocol Agent (BPA) (as defined in [refs.DTNBP]) that is processing
bundles within the context of a Delay-Tolerant Network architecture
 [refs.DTNarch].  It defines an operation called "diversion", which is
the act of a bundle protocol agent moving an entire bundle from some
point in bundle processing in the BPA to a DTN application agent.
This diversion of a bundle from the BPA to an application agent is
distinct from delivery of the bundle at that application agent.  This
document defines a second operation, called "injection", which is the
inverse of diversion.  Injection is the act of an application agent
moving an entire bundle from the application agent into some point in
bundle processing in the BPA.  This injection of a bundle from an
application agent to the BPA is distinct from bundle transmission.

Bundle diversion is expected to be of general utility in DTN in instances i=
n which all or part of a bundle needs to be transcoded while the bundle is =
being forwarded through the network. A bundle that is received at a BPA in =
one coding format can be diverted to an application agent that has as its p=
urpose the conversion of the bundle to an alternate coding format. After tr=
anscoding, an application agent can inject a transcoded bundle back into BP=
A processing to be forwarded or delivered in its new format. Bundle-in-bund=
le encapsulation is a specific example of a use case that has been identifi=
ed for bundle diversion. In order to perform encapsulation, bundle diversio=
n is required to move the bundle to be encapsulated from BPA processing to =
the encapsulating application agent at the start of the tunnel, and bundle =
injection is required to move the de-encapsulated bundle from the de-encaps=
ulating application agent back into BPA bundle processing at the end of the=
 tunnel.

We are interested in hearing your feedback. Thanks.

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
From: Symington, Susan F.
Sent: Monday, February 02, 2009 3:26 PM
To: dtn interest
Subject: DTN bundle diversion and encapsulatin I-Ds

DTN RG:

I just submitted two DTN I-Ds that are related to each other, DTN Bundle Di=
version (draft-irtf-dtnrg-bundle-divert-00) and DTN Bundle-in-Bundle Encaps=
ulation (draft-irtf-dtnrg-bundle-encapsulation-05).

As I discussed at the Minneapolis meeting, the Bundle Diversion draft enhan=
ces RFC 5050 by introducing two new concepts: bundle diversion and bundle i=
njection. "Diversion" is the act of a bundle protocol agent moving an entir=
e bundle from some point in bundle processing in the BPA to a DTN applicati=
on agent. This diversion of a bundle from the BPA to an application agent i=
s distinct from delivery of the bundle at that application agent.  "Injecti=
on" is the inverse of diversion. It is the act of an application agent movi=
ng an entire bundle from the application agent into some point in bundle pr=
ocessing in the BPA.  This injection of a bundle from an application agent =
to the BPA is distinct from bundle transmission. Diversion might take place=
, for example, at the entrance to an encapsulation tunnel and injection mig=
ht take place at the other end of that tunnel.

The Bundle-in-Bundle Encapsulation I-D now just defines the capability and =
format for placing one or more bundles inside of the payload field of an en=
capsulating bundle's Bundle Payload Block.

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC022844685DIMCMBX2MITREO_
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:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/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/sharepoin=
t/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://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xm=
lns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D=
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schem=
as.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.mi=
crosoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsof=
t.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/=
package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats=
.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/off=
ice/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/=
2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpa=
ges" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/typ=
es" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/mess=
ages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibr=
ary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer=
/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:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 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:10.5pt;
	font-family:Consolas;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
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.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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:62916340;
	mso-list-type:hybrid;
	mso-list-template-ids:-1072016468 1227896916 1827327578 7349258 -96316496 =
-246634328 -558079688 43043732 -2109176070 -1352487542;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\2013;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Arial","sans-serif";
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:\2013;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Arial","sans-serif";
	mso-bidi-font-family:"Times New Roman";}
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'color:#1F497D'>Hello DTNRG,<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Has anyone had a chance =
to read
through the DTN Bundle Diversion I-D (<a
href=3D"http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-divert-=
00.txt">http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-divert-=
00.txt</a>)
and the revised DTN Bundle-in-Bundle Encapsulation I-D (<a
href=3D"http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-encapsu=
lation-05.txt">http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-=
encapsulation-05.txt</a>)
that we submitted earlier this month? We are interested in hearing feedback=
 on these
drafts. What do folks think?<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The drafts are intended =
to
address concerns that were raised to a previous version of the Bundle-in-Bu=
ndle
Encapsulation I-D.&nbsp; The Bundle Diversion I-D was created to define a
general capability to divert a bundle from the forwarding chain for process=
ing
by an application agent, with one particular use case being diversion of a
bundle to an application agent that performs encapsulation. &nbsp;The Bundl=
e-in-Bundle
Encapsulation I-D now just defines the encapsulation format.<o:p></o:p></sp=
an></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Here is the abstract fro=
m the DTN
Bundle Diversion I-D:<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>Abstract<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>This
document defines two extensions to the capabilities of a Bundle<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>Protocol
Agent (BPA) (as defined in [refs.DTNBP]) that is processing<o:p></o:p></spa=
n></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>bundles
within the context of a Delay-Tolerant Network architecture<o:p></o:p></spa=
n></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>&nbsp;[refs.DTNarch].&nbsp;
It defines an operation called &quot;diversion&quot;, which is<o:p></o:p></=
span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>the
act of a bundle protocol agent moving an entire bundle from some<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>point
in bundle processing in the BPA to a DTN application agent.<o:p></o:p></spa=
n></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>This
diversion of a bundle from the BPA to an application agent is<o:p></o:p></s=
pan></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>distinct
from delivery of the bundle at that application agent.&nbsp; This<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>document
defines a second operation, called &quot;injection&quot;, which is the<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>inverse
of diversion.&nbsp; Injection is the act of an application agent<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>moving
an entire bundle from the application agent into some point in<o:p></o:p></=
span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>bundle
processing in the BPA.&nbsp; This injection of a bundle from an<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>application
agent to the BPA is distinct from bundle transmission.<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Bundle diversion is expe=
cted to
be of general utility in DTN in instances in which all or part of a bundle
needs to be transcoded while the bundle is being forwarded through the netw=
ork.
A bundle that is received at a BPA in one coding format can be diverted to =
an
application agent that has as its purpose the conversion of the bundle to a=
n
alternate coding format. After transcoding, an application agent can inject=
 a
transcoded bundle back into BPA processing to be forwarded or delivered in =
its
new format. Bundle-in-bundle encapsulation is a specific example of a use c=
ase
that has been identified for bundle diversion. In order to perform
encapsulation, bundle diversion is required to move the bundle to be
encapsulated from BPA processing to the encapsulating application agent at =
the
start of the tunnel, and bundle injection is required to move the
de-encapsulated bundle from the de-encapsulating application agent back int=
o
BPA bundle processing at the end of the tunnel.</span><span style=3D'font-s=
ize:
10.0pt;font-family:"Courier New"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>We are interested in hea=
ring
your feedback. Thanks.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>-susan<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:#1F497D'>************************************************************=
*****</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew";
color:#1F497D'>Susan Symington</span><span style=3D'font-size:12.0pt;font-f=
amily:
"Times New Roman","serif";color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew";
color:#1F497D'>The MITRE Corporation</span><span style=3D'font-size:12.0pt;
font-family:"Times New Roman","serif";color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew";
color:#1F497D'>[email-masked]</span><span style=3D'font-size:12.0pt;font-f=
amily:
"Times New Roman","serif";color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew";
color:#1F497D'>703-983-7209 (voice)</span><span style=3D'font-size:12.0pt;
font-family:"Times New Roman","serif";color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew";
color:#1F497D'>703-983-7142 (fax)</span><span style=3D'font-size:12.0pt;
font-family:"Times New Roman","serif";color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:#1F497D'>************************************************************=
******</span><span
style=3D'color:#1F497D'><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"'> Symington, Su=
san F.
<br>
<b>Sent:</b> Monday, February 02, 2009 3:26 PM<br>
<b>To:</b> dtn interest<br>
<b>Subject:</b> DTN bundle diversion and encapsulatin I-Ds<o:p></o:p></span=
></p>

</div>

</div>

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

<p class=3DMsoNormal>DTN RG:<o:p></o:p></p>

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

<p class=3DMsoNormal>I just submitted two DTN I-Ds that are related to each
other, DTN Bundle Diversion (draft-irtf-dtnrg-bundle-divert-00) and DTN
Bundle-in-Bundle Encapsulation (draft-irtf-dtnrg-bundle-encapsulation-05).<=
o:p></o:p></p>

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

<p class=3DMsoNormal>As I discussed at the Minneapolis meeting, the Bundle
Diversion draft enhances RFC 5050 by introducing two new concepts: bundle
diversion and bundle injection. &quot;Diversion&#8221; is the act of a bund=
le
protocol agent moving an entire bundle from some point in bundle processing=
 in
the BPA to a DTN application agent. This diversion of a bundle from the BPA=
 to
an application agent is distinct from delivery of the bundle at that
application agent.&nbsp; &#8220;Injection&#8221; is the inverse of diversio=
n.
It is the act of an application agent moving an entire bundle from the
application agent into some point in bundle processing in the BPA.&nbsp; Th=
is
injection of a bundle from an application agent to the BPA is distinct from
bundle transmission. Diversion might take place, for example, at the entran=
ce
to an encapsulation tunnel and injection might take place at the other end =
of
that tunnel.<o:p></o:p></p>

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

<p class=3DMsoNormal>The Bundle-in-Bundle Encapsulation I-D now just define=
s the
capability and format for placing one or more bundles inside of the payload
field of an encapsulating bundle's Bundle Payload Block.<o:p></o:p></p>

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

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>-susan<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
**</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>Susan
Symington</span><span style=3D'font-size:12.0pt;font-family:"Times New Roma=
n","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>The
MITRE Corporation</span><span style=3D'font-size:12.0pt;font-family:"Times =
New Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>[email-masked]</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7209
(voice)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman"=
,"serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7142
(fax)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman","=
serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
***</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC022844685DIMCMBX2MITREO_--

From: Peter TB Brett <[email-masked]>
Organization: Integral Informatics Ltd
To: [email-masked]
Sender: Peter TB Brett <[email-masked]>
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block
Date: Thu, 12 Feb 2009 08:04:07 -0000

--nextPart9136181.mmdxUalWdM
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 12 February 2009 00:04:46 Parikh, Salil wrote:

> This document defines an optional Bundle Protocol block called the
> Superseding Bundle Extension Block (SBEB) for use with the Bundle Protocol
> in the context of the Delay-Tolerant Networking Architecture.  Applicatio=
ns
> use this block to call for the removal of previously sent bundles that are
> rendered obsolete by more recent bundles.

Some more discussion of security considerations would have been nice -- for=
=20
instance, attacks using bundles with SBEB blocks to replace other nodes' da=
ta=20
do not seem to be discussed.

                              Peter

=2D-=20
Peter Brett

Electronic Systems Engineer
Integral Informatics Ltd

--nextPart9136181.mmdxUalWdM
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart9136181.mmdxUalWdM--

Date: Thu, 12 Feb 2009 12:33:42 +0530
From: Prithwish Basu <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Hierarchy

Hi Scott,

We had a paper in Milcom last year about some aspects of the late 
binding problem. Here's a pointer:

http://www.ir.bbn.com/~pbasu/pubs/milcom08.pdf

The network of name knowledge bases (hosted at progressive resolvers) 
mentioned in the paper can be used to achieve something like this.  A 
NameKB hosted at each node can have arbitrarily complex transformation 
rules which take in the immutable name (or name query in case of anycast 
style names) and output the "canonical DTN name" of a resolver node 
potentially after a series of transformations (these rules may be chained).

Also, the metadata extension block was used to carry hint information 
stamped by intermediate resolvers. Obviously, the scalability problem 
caused by a combination of non-aggregatable namespaces and arbitrary 
disruption patterns is the hardest one to solve here (if not impossible) 
but for statically configured and predictable scenarios and also for 
mobile scenarios with available geographic information, it is more 
tractable, I think.

Let me know if you have any thoughts on this.

thanks!
-Prithwish

Burleigh, Scott C wrote:
>> -----Original Message-----
>> From: Peter Lovell [mailto:[email-masked]]
>> Sent: Wednesday, February 11, 2009 2:43 PM
>> To: Burleigh, Scott C; dtn interest
>> Subject: Re(2): [dtn-interest] Hierarchy
>>
>> Hi Scott,
>>
>> this looks to be an interesting and productive approach.
>>
>> I think what you mean by this part ...
>>
>>     
>>> An endpoint may have an immutable name in a flat namespace, but security
>>> databases and local routing databases may individually map that name to
>>> very different classification locators -- maybe other names in
>>> hierarchical namespaces that have local significance, maybe to
>>> addresses, whatever -- and that mapping may be quite dynamic.
>>>       
>> ... is that, using familiar syntax for sake of example, a message might
>> be sent to [email-masked] and another to [email-masked] and
>> both would be delivered to [email-masked], since that's what the
>> database maps show as the delivery address for those initial address
>> specification.
>>
>> So the addresses don't have mutable parts (recalling a discussion from
>> some months ago) but the destination address would be updated as the
>> message was forwarded etc.
>>     
>
> That's not exactly what I meant, though close: I figure the destination (a name) would never change but at each forwarding point that name might be mapped to a token that is useful for the routing decision that must be made at that point.
>
> For example, the destination of the bundle is p_smith.dtn but the first router it hits has never heard of p_smith.dtn.  However that router does know how to forward bundles to people based on where they work, so it looks up "p_smith" in its Where They Work database and gets Yoyodyne.dtn.  Now it looks for Yoyodyne.dtn its routing table, encounters the *dyne.dtn entry, and forwards the bundle to the node associated with that entry for further forwarding.
>
> Scott
>
>   
>> On Fri, Feb 6, 2009, Burleigh, Scott C <[email-masked]>
>> wrote:
>>
>>     
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:dtn-
>>>> [email-masked]] On Behalf Of Ivancic,
>>>> William D. (GRC-RHN0)
>>>> Sent: Friday, February 06, 2009 2:14 PM
>>>> To: [email-masked]
>>>> Subject: [dtn-interest] Hierarchy
>>>>
>>>> We have been looking a dtn naming for space systems.  I have also
>>>>         
>> been
>>     
>>>> trying to consider all types of DTN applications, not just space.  I
>>>> have been struggling with the concept of  hierarchy in a DTN.
>>>>
>>>> Because of late binding, it is difficult (at least for me) to
>>>>         
>> formulate
>>     
>>>> a naming to addressing scheme that has hierarchy.  Is a byproduct of
>>>> "late binding" a flat network?
>>>>
>>>> Part of this question is a result of contemplating DTN security.  I
>>>>         
>> can
>>     
>>>> foresee wanting to do filtering similar to IPsec where one might say
>>>> have policy that says Bundles from Network A and C may pass, but
>>>> bundles from Network B and E get dropped.  Unfortunately, the bundle
>>>> agents keep looking like nodes (hosts) to me with a flat DTN network
>>>> topology  - even if that DTN spans multiple-types of convergence
>>>>         
>> layers
>>     
>>>> (i.e. IP, Bluetooth, CCSDS).
>>>>
>>>> I can see having structure to a name such that it may have an
>>>>         
>> identity
>>     
>>>> piece and a domain piece, etcetera, similar to a Fully Qualified
>>>>         
>> Domain
>>     
>>>> Name.  Thus, I can picture Hierarchy in the naming, but not the
>>>> routing.  Therefore, I could do filtering on the naming for security
>>>> reasons, but I don't see how one would do route aggregation with
>>>>         
>> late
>>     
>>>> binding.
>>>>
>>>> What am I missing?
>>>>         
>>> I have been puzzling over this too, Will, but I have lately begun to
>>> feel comfortable with a notion that came to me just in the last week
>>>       
>> or
>>     
>>> so.  While I agree that late binding seems to favor flat namespaces
>>>       
>> (by
>>     
>>> making hierarchy in naming less advantageous, because the name may
>>>       
>> need
>>     
>>> to be bound in different ways at different points in the end-to-end
>>> path), I think we may be able to make this work for us rather than
>>>       
>> against us.
>>     
>>> The concept I'm working with is sort of role-based.  Imagine that you
>>> are a person named Pat Smith who (a) works at Yoyodyne Inc., (b) is a
>>> member of the Duluth Athletic Club, (c) is taking classes at
>>>       
>> University
>>     
>>> of Denver.  You occupy a job at Yoyodyne that is at some location in a
>>> hierarchy; you are signed up for yoga classes at DAC but not badminton
>>> or volleyball; you are a sophomore at U. of D.  But your name doesn't
>>> reflect any of these classifications, hierarchical or not.  Instead,
>>> there are databases at Yoyodyne, DAC, and U. of D. that map your name
>>> into the appropriate classification locators.
>>>
>>> I think the same thing can work for routing and security in a DTN.  An
>>> endpoint may have an immutable name in a flat namespace, but security
>>> databases and local routing databases may individually map that name
>>>       
>> to
>>     
>>> very different classification locators -- maybe other names in
>>> hierarchical namespaces that have local significance, maybe to
>>> addresses, whatever -- and that mapping may be quite dynamic.
>>>
>>> The advantage of this approach, I think, is that it is very powerful,
>>> highly extensible, and in every individual instance quite simple.  The
>>> disadvantage is that when you look at the job of keeping all of this
>>> mapping infrastructure current and usable it may look kind of
>>>       
>> daunting.
>>     
>>> But I would suggest that we do complicated things like this all the
>>> time, with generally pretty good results: we get arbitrarily complex
>>> infrastructure and behavior by aggregating lots of individually simple
>>> infrastructure components.
>>>
>>> Scott
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>       
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>   

From: "Burleigh, Scott C" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Wed, 11 Feb 2009 21:17:39 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  Hierarchy

> -----Original Message-----
> From: Peter Lovell [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2009 2:43 PM
> To: Burleigh, Scott C; dtn interest
> Subject: Re(2): [dtn-interest] Hierarchy
>
> Hi Scott,
>
> this looks to be an interesting and productive approach.
>
> I think what you mean by this part ...
>
> >An endpoint may have an immutable name in a flat namespace, but security
> >databases and local routing databases may individually map that name to
> >very different classification locators -- maybe other names in
> >hierarchical namespaces that have local significance, maybe to
> >addresses, whatever -- and that mapping may be quite dynamic.
>
> ... is that, using familiar syntax for sake of example, a message might
> be sent to [email-masked] and another to [email-masked] and
> both would be delivered to [email-masked], since that's what the
> database maps show as the delivery address for those initial address
> specification.
>
> So the addresses don't have mutable parts (recalling a discussion from
> some months ago) but the destination address would be updated as the
> message was forwarded etc.

That's not exactly what I meant, though close: I figure the destination (a name) would never change but at each forwarding point that name might be mapped to a token that is useful for the routing decision that must be made at that point.

For example, the destination of the bundle is p_smith.dtn but the first router it hits has never heard of p_smith.dtn.  However that router does know how to forward bundles to people based on where they work, so it looks up "p_smith" in its Where They Work database and gets Yoyodyne.dtn.  Now it looks for Yoyodyne.dtn its routing table, encounters the *dyne.dtn entry, and forwards the bundle to the node associated with that entry for further forwarding.

Scott

> On Fri, Feb 6, 2009, Burleigh, Scott C <[email-masked]>
> wrote:
>
> >> -----Original Message-----
> >> From: [email-masked] [mailto:dtn-
> >> [email-masked]] On Behalf Of Ivancic,
> >> William D. (GRC-RHN0)
> >> Sent: Friday, February 06, 2009 2:14 PM
> >> To: [email-masked]
> >> Subject: [dtn-interest] Hierarchy
> >>
> >> We have been looking a dtn naming for space systems.  I have also
> been
> >> trying to consider all types of DTN applications, not just space.  I
> >> have been struggling with the concept of  hierarchy in a DTN.
> >>
> >> Because of late binding, it is difficult (at least for me) to
> formulate
> >> a naming to addressing scheme that has hierarchy.  Is a byproduct of
> >> "late binding" a flat network?
> >>
> >> Part of this question is a result of contemplating DTN security.  I
> can
> >> foresee wanting to do filtering similar to IPsec where one might say
> >> have policy that says Bundles from Network A and C may pass, but
> >> bundles from Network B and E get dropped.  Unfortunately, the bundle
> >> agents keep looking like nodes (hosts) to me with a flat DTN network
> >> topology  - even if that DTN spans multiple-types of convergence
> layers
> >> (i.e. IP, Bluetooth, CCSDS).
> >>
> >> I can see having structure to a name such that it may have an
> identity
> >> piece and a domain piece, etcetera, similar to a Fully Qualified
> Domain
> >> Name.  Thus, I can picture Hierarchy in the naming, but not the
> >> routing.  Therefore, I could do filtering on the naming for security
> >> reasons, but I don't see how one would do route aggregation with
> late
> >> binding.
> >>
> >> What am I missing?
> >
> >I have been puzzling over this too, Will, but I have lately begun to
> >feel comfortable with a notion that came to me just in the last week
> or
> >so.  While I agree that late binding seems to favor flat namespaces
> (by
> >making hierarchy in naming less advantageous, because the name may
> need
> >to be bound in different ways at different points in the end-to-end
> >path), I think we may be able to make this work for us rather than
> against us.
> >
> >The concept I'm working with is sort of role-based.  Imagine that you
> >are a person named Pat Smith who (a) works at Yoyodyne Inc., (b) is a
> >member of the Duluth Athletic Club, (c) is taking classes at
> University
> >of Denver.  You occupy a job at Yoyodyne that is at some location in a
> >hierarchy; you are signed up for yoga classes at DAC but not badminton
> >or volleyball; you are a sophomore at U. of D.  But your name doesn't
> >reflect any of these classifications, hierarchical or not.  Instead,
> >there are databases at Yoyodyne, DAC, and U. of D. that map your name
> >into the appropriate classification locators.
> >
> >I think the same thing can work for routing and security in a DTN.  An
> >endpoint may have an immutable name in a flat namespace, but security
> >databases and local routing databases may individually map that name
> to
> >very different classification locators -- maybe other names in
> >hierarchical namespaces that have local significance, maybe to
> >addresses, whatever -- and that mapping may be quite dynamic.
> >
> >The advantage of this approach, I think, is that it is very powerful,
> >highly extensible, and in every individual instance quite simple.  The
> >disadvantage is that when you look at the job of keeping all of this
> >mapping infrastructure current and usable it may look kind of
> daunting.
> >But I would suggest that we do complicated things like this all the
> >time, with generally pretty good results: we get arbitrarily complex
> >infrastructure and behavior by aggregating lots of individually simple
> >infrastructure components.
> >
> >Scott
> >
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: "Parikh, Salil" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 11 Feb 2009 19:04:46 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

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

Not that this is a new idea...

See Section 3.2.12 of http://www.ietf.org/internet-drafts/draft-ietf-usefor=
-usefor-12.txt

And: Section 6.14 of http://www.eyrie.org/~eagle/usefor/other/son-of-1036

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Parikh, Salil
Sent: Wednesday, January 07, 2009 10:30 AM
To: [email-masked]
Subject: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle E=
xtension Block

Hello,

We have submitted an Internet-Draft titled "Delay-Tolerant Networking Super=
seding Bundle Extension Block".  We welcome review and comment from the DTN=
RG community.

http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extensi=
on-block-00.txt

Abstract:

This document defines an optional Bundle Protocol block called the Supersed=
ing Bundle Extension Block (SBEB) for use with the Bundle Protocol in the c=
ontext of the Delay-Tolerant Networking Architecture.  Applications use thi=
s block to call for the removal of previously sent bundles that are rendere=
d obsolete by more recent bundles. Upon receiving a bundle with an SBEB, a =
node will search its bundle store (and outbound queues) for bundles that ar=
e obsoleted by other related bundles according to their source and destinat=
ion EID, and the SBEB cookie (if present), and may delete some or all of th=
em. Discarding obsolete bundles helps conserve storage space and prevents e=
xpending resources in further forwarding bundles that are no longer relevan=
t.  The bundle protocol already uses expiration times to remove bundles tha=
t are no longer useful to applications.  The SBEB is a way for applications=
 to mark bundles that a node may delete prior to their expiration times.

--_000_06CBA47B9C3FA7409BF459DAA035248902C7F66AEDIMCMBX3MITREO_
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:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/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/sharepoin=
t/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://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xm=
lns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D=
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schem=
as.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.mi=
crosoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsof=
t.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/=
package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats=
.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/off=
ice/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/=
2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpa=
ges" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/typ=
es" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/mess=
ages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibr=
ary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer=
/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: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: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;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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><span style=3D'color:#1F497D'>Not that this is a new i=
dea...<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>See Section 3.2.12 of <a
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-12.txt=
">http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-12.txt</a><o=
:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>And: Section 6.14 of <a
href=3D"http://www.eyrie.org/~eagle/usefor/other/son-of-1036">http://www.ey=
rie.org/~eagle/usefor/other/son-of-1036</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

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

<p class=3DMsoNormal style=3D'margin-left:.5in'><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"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Parikh,
Salil<br>
<b>Sent:</b> Wednesday, January 07, 2009 10:30 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [dtn-interest] I-D: Delay-Tolerant Networking Superseding
Bundle Extension Block<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'>Hello,<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'>We have submitted an Intern=
et-Draft
titled &#8220;Delay-Tolerant Networking Superseding Bundle Extension
Block&#8221;.&nbsp; We welcome review and comment from the DTNRG community.=
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><a
href=3D"http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding=
-extension-block-00.txt">http://www.ietf.org/internet-drafts/draft-parikh-b=
undle-superseding-extension-block-00.txt</a><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'>Abstract:<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'>This document defines an op=
tional
Bundle Protocol block called the Superseding Bundle Extension Block (SBEB) =
for
use with the Bundle Protocol in the context of the Delay-Tolerant Networkin=
g
Architecture.&nbsp; Applications use this block to call for the removal of
previously sent bundles that are rendered obsolete by more recent bundles. =
Upon
receiving a bundle with an SBEB, a node will search its bundle store (and
outbound queues) for bundles that are obsoleted by other related bundles
according to their source and destination EID, and the SBEB cookie (if
present), and may delete some or all of them. Discarding obsolete bundles h=
elps
conserve storage space and prevents expending resources in further forwardi=
ng bundles
that are no longer relevant.&nbsp; The bundle protocol already uses expirat=
ion
times to remove bundles that are no longer useful to applications.&nbsp; Th=
e
SBEB is a way for applications to mark bundles that a node may delete prior=
 to
their expiration times.<o:p></o:p></p>

</div>

</body>

</html>

--_000_06CBA47B9C3FA7409BF459DAA035248902C7F66AEDIMCMBX3MITREO_--

From: Peter Lovell <[email-masked]>
To: Scott Burleigh <[email-masked]>, dtn interest <[email-masked]>
Date: Wed, 11 Feb 2009 17:43:16 -0500
Subject: [dtn-interest] Re(2):  Hierarchy

Hi Scott,

this looks to be an interesting and productive approach.

I think what you mean by this part ...

>An endpoint may have an immutable name in a flat namespace, but security
>databases and local routing databases may individually map that name to
>very different classification locators -- maybe other names in
>hierarchical namespaces that have local significance, maybe to
>addresses, whatever -- and that mapping may be quite dynamic.

... is that, using familiar syntax for sake of example, a message might
be sent to [email-masked] and another to [email-masked] and
both would be delivered to [email-masked], since that's what the
database maps show as the delivery address for those initial address
specification.

So the addresses don't have mutable parts (recalling a discussion from
some months ago) but the destination address would be updated as the
message was forwarded etc.

Do I have this right, or do I misunderstand?

Thanks.....Peter

On Fri, Feb 6, 2009, Burleigh, Scott C <[email-masked]> wrote:

>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Ivancic,
>> William D. (GRC-RHN0)
>> Sent: Friday, February 06, 2009 2:14 PM
>> To: [email-masked]
>> Subject: [dtn-interest] Hierarchy
>>
>> We have been looking a dtn naming for space systems.  I have also been
>> trying to consider all types of DTN applications, not just space.  I
>> have been struggling with the concept of  hierarchy in a DTN.
>>
>> Because of late binding, it is difficult (at least for me) to formulate
>> a naming to addressing scheme that has hierarchy.  Is a byproduct of
>> "late binding" a flat network?
>>
>> Part of this question is a result of contemplating DTN security.  I can
>> foresee wanting to do filtering similar to IPsec where one might say
>> have policy that says Bundles from Network A and C may pass, but
>> bundles from Network B and E get dropped.  Unfortunately, the bundle
>> agents keep looking like nodes (hosts) to me with a flat DTN network
>> topology  - even if that DTN spans multiple-types of convergence layers
>> (i.e. IP, Bluetooth, CCSDS).
>>
>> I can see having structure to a name such that it may have an identity
>> piece and a domain piece, etcetera, similar to a Fully Qualified Domain
>> Name.  Thus, I can picture Hierarchy in the naming, but not the
>> routing.  Therefore, I could do filtering on the naming for security
>> reasons, but I don't see how one would do route aggregation with late
>> binding.
>>
>> What am I missing?
>
>I have been puzzling over this too, Will, but I have lately begun to
>feel comfortable with a notion that came to me just in the last week or
>so.  While I agree that late binding seems to favor flat namespaces (by
>making hierarchy in naming less advantageous, because the name may need
>to be bound in different ways at different points in the end-to-end
>path), I think we may be able to make this work for us rather than
against us.
>
>The concept I'm working with is sort of role-based.  Imagine that you
>are a person named Pat Smith who (a) works at Yoyodyne Inc., (b) is a
>member of the Duluth Athletic Club, (c) is taking classes at University
>of Denver.  You occupy a job at Yoyodyne that is at some location in a
>hierarchy; you are signed up for yoga classes at DAC but not badminton
>or volleyball; you are a sophomore at U. of D.  But your name doesn't
>reflect any of these classifications, hierarchical or not.  Instead,
>there are databases at Yoyodyne, DAC, and U. of D. that map your name
>into the appropriate classification locators.
>
>I think the same thing can work for routing and security in a DTN.  An
>endpoint may have an immutable name in a flat namespace, but security
>databases and local routing databases may individually map that name to
>very different classification locators -- maybe other names in
>hierarchical namespaces that have local significance, maybe to
>addresses, whatever -- and that mapping may be quite dynamic.
>
>The advantage of this approach, I think, is that it is very powerful,
>highly extensible, and in every individual instance quite simple.  The
>disadvantage is that when you look at the job of keeping all of this
>mapping infrastructure current and usable it may look kind of daunting.
>But I would suggest that we do complicated things like this all the
>time, with generally pretty good results: we get arbitrarily complex
>infrastructure and behavior by aggregating lots of individually simple
>infrastructure components.
>
>Scott
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 6 Feb 2009 16:01:11 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Hierarchy

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Ivancic,
> William D. (GRC-RHN0)
> Sent: Friday, February 06, 2009 2:14 PM
> To: [email-masked]
> Subject: [dtn-interest] Hierarchy
>
> We have been looking a dtn naming for space systems.  I have also been
> trying to consider all types of DTN applications, not just space.  I
> have been struggling with the concept of  hierarchy in a DTN.
>
> Because of late binding, it is difficult (at least for me) to formulate
> a naming to addressing scheme that has hierarchy.  Is a byproduct of
> "late binding" a flat network?
>
> Part of this question is a result of contemplating DTN security.  I can
> foresee wanting to do filtering similar to IPsec where one might say
> have policy that says Bundles from Network A and C may pass, but
> bundles from Network B and E get dropped.  Unfortunately, the bundle
> agents keep looking like nodes (hosts) to me with a flat DTN network
> topology  - even if that DTN spans multiple-types of convergence layers
> (i.e. IP, Bluetooth, CCSDS).
>
> I can see having structure to a name such that it may have an identity
> piece and a domain piece, etcetera, similar to a Fully Qualified Domain
> Name.  Thus, I can picture Hierarchy in the naming, but not the
> routing.  Therefore, I could do filtering on the naming for security
> reasons, but I don't see how one would do route aggregation with late
> binding.
>
> What am I missing?

I have been puzzling over this too, Will, but I have lately begun to feel comfortable with a notion that came to me just in the last week or so.  While I agree that late binding seems to favor flat namespaces (by making hierarchy in naming less advantageous, because the name may need to be bound in different ways at different points in the end-to-end path), I think we may be able to make this work for us rather than against us.

The concept I'm working with is sort of role-based.  Imagine that you are a person named Pat Smith who (a) works at Yoyodyne Inc., (b) is a member of the Duluth Athletic Club, (c) is taking classes at University of Denver.  You occupy a job at Yoyodyne that is at some location in a hierarchy; you are signed up for yoga classes at DAC but not badminton or volleyball; you are a sophomore at U. of D.  But your name doesn't reflect any of these classifications, hierarchical or not.  Instead, there are databases at Yoyodyne, DAC, and U. of D. that map your name into the appropriate classification locators.

I think the same thing can work for routing and security in a DTN.  An endpoint may have an immutable name in a flat namespace, but security databases and local routing databases may individually map that name to very different classification locators -- maybe other names in hierarchical namespaces that have local significance, maybe to addresses, whatever -- and that mapping may be quite dynamic.

The advantage of this approach, I think, is that it is very powerful, highly extensible, and in every individual instance quite simple.  The disadvantage is that when you look at the job of keeping all of this mapping infrastructure current and usable it may look kind of daunting.  But I would suggest that we do complicated things like this all the time, with generally pretty good results: we get arbitrarily complex infrastructure and behavior by aggregating lots of individually simple infrastructure components.

Scott

Date: Fri, 06 Feb 2009 22:48:09 +0000
From: Stephen Farrell <[email-masked]>
To: Rajesh Krishnan <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN Network Management Meeting Notes January 21 and February 2, 2009

Rajesh Krishnan wrote:
> This group should consider whether scheduling of mobile assets (based
> on traffic requirements) to extend the network footprint ought to be
> within scope.  

Well as a research group we have plenty of scope so feel free to go
ahead and do the work!

S.

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 6 Feb 2009 16:13:43 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Hierarchy

We have been looking a dtn naming for space systems.  I have also been trying to consider all types of DTN applications, not just space.  I have been struggling with the concept of  hierarchy in a DTN.

Because of late binding, it is difficult (at least for me) to formulate a naming to addressing scheme that has hierarchy.  Is a byproduct of "late binding" a flat network?

Part of this question is a result of contemplating DTN security.  I can foresee wanting to do filtering similar to IPsec where one might say have policy that says Bundles from Network A and C may pass, but bundles from Network B and E get dropped.  Unfortunately, the bundle agents keep looking like nodes (hosts) to me with a flat DTN network topology  - even if that DTN spans multiple-types of convergence layers (i.e. IP, Bluetooth, CCSDS).  

I can see having structure to a name such that it may have an identity piece and a domain piece, etcetera, similar to a Fully Qualified Domain Name.  Thus, I can picture Hierarchy in the naming, but not the routing.  Therefore, I could do filtering on the naming for security reasons, but I don't see how one would do route aggregation with late binding.

What am I missing?

/Will

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Rajesh Krishnan <[email-masked]>
Date: Fri, 6 Feb 2009 15:50:47 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN Network Management Meeting Notes January 21 and February 2, 2009

> I agree with the core purposes of network management listed, 
> and I wonder if you consider resource management a special 
> case of configuration.  

I certainly consider it a case of configuration.  I don't know if this is "special" or will be normal for a DTN bundle agent.  We have a lot to learn once we widely begin deploying store-and-forward systems - bundling or otherwise.

>DTN characteristics require extending 
> traditional network management to storage resource management 
> and mobile resource management.
> 

I can see where I may want to share some capacity for general users and reserve some for my systems - or at least give priority to my systems.

> This group should consider whether scheduling of mobile 
> assets (based on traffic requirements) to extend the network 
> footprint ought to be within scope.  A sub-case is the 
> exchange of schedules via NMD.  There are a number of robotic 
> network and autonomous vehicular network situations where 
> cooperative management of communications and mobility is 
> desirable (e.g., exploration and mapping by a robotic team).
> 
> Best Regards,
> Rajesh

/will

Date: Fri, 6 Feb 2009 16:42:56 -0500
From: Rajesh Krishnan <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN Network Management Meeting Notes January 21 and February 2, 2009

Will:

Thanks very much for posting the notes.

I agree with the core purposes of network management listed, and I
wonder if you consider resource management a special case of
configuration.  DTN characteristics require extending traditional
network management to storage resource management and mobile resource
management.

This group should consider whether scheduling of mobile assets (based
on traffic requirements) to extend the network footprint ought to be
within scope.  A sub-case is the exchange of schedules via NMD.  There
are a number of robotic network and autonomous vehicular network
situations where cooperative management of communications and mobility
is desirable (e.g., exploration and mapping by a robotic team).

Best Regards,
Rajesh

On Fri, Feb 6, 2009 at 4:03 PM, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:
> DTN Network Management - Collaborators
> Meeting Notes for
> Wednesday, January 21 and Monday February 2, 2009
> 1:00 - 2:00 EST (18:00 - 19:00 UTC)
>
> A teleconference was held on Wednesday, January 21, 2009 due to Martin Luther King Day and the Inauguration.  Another very short teleconference was held Monday, February 2nd.  These notes are a combination of those two teleconferences.
>
> The following teleconference will be, Monday, February 16, 2009.
>
>
> Participants:
> *       BBN - Cambridge
> *       Hans Kruse, Shawn Ostermann  - Ohio University
> *       Will Ivancic, Joseph Ishac, Wes Eddy - NASA Glenn
> *       Scott Burleigh - NASA JPL
> *       Ed Birrane and others   - Applied Physics Lab
> *       Keith Scott - MITRE
> *       Simon Perreault - Viagenie
>
> Agenda 21-Jan-2009
> ==================
> UAV scenario - description yet to be written down (Ivancic)
>
> Open Discussion
>
> Agenda 2-Feb-2009
> =================
> DTNRG is meeting March 19 and 20th at Google in Mountain View, California USA.  In addition, I believe Stephen requested 1 hour at IETF (San Francisco).
>  - Agenda yet to be sent for the March 19-20.
>    -> We probably should request some time and topics.
>    -> Who is planning to attend IRTF DTNRG and IETF?
>
> Available DTN Testbeds / DTN interconnected sites.
>
>
>
> General Discussion
> -----------------------
> * Scott Burleigh sent out a write up on the network management performed via DINET to the NASA internal group.  This has yet to be cleared for general release.
>
> * Will Ivancic has not been able to make any progress on the Draft due to other priorities.  Work should commence with UAV scenario
>
> * Short discussion on John Day's book, "Patterns in Network Architecture - A Return to Fundamentals"  regarding network management and the history around the decision to use SNMP versus High-Level Entity Management System (HEMS).
>
> * Discussion of RFC 1757, Remote Network Management Information Base
>  - Need to rethink transport for DTN Network Management.
>  - It may be wise to investigate RMON (Remote Monitoring) for Data Representation and other ideas.
>
> * Ed Birrane of Applied Physics Labs (APL) set up a wiki for use by the network management team.  For the time being, access will be restricted via username/password. Instructions for access are in the list archive email of Jan 23 from Ed Birrane.
>
>
> Available DTN Bundling/Forwarding Agents
> -------------------------------------------------------
> * Ohio University and Glenn Research are both considering establishing DTN bundle agent directories via wikis.   (As a result, Will Ivancic sent a request to Stephen Farrel and Kevin Fall suggesting that the DTNRG wiki be used for this purpose.  This would provide a single location instead of a multitude of wikis that need to be searched for information.  The proposal is currently under consideration.)
>
> * Glenn Research Center has a DTN bundle agent up, but no hostname entry in the DNS yet.  That is being worked.  This bundle agent has both ION and DTN-2 implementations.  As soon as we decide which wiki the location capability information will reside in, we will update the wiki and send the information to the DTNRG group.
>
> * Some discussion between GRC and Ohio University on getting ION bundle agents configured properly to pass bundles.  The configuration information should be on the Ohio University ION code distribution site.  Scott Burleigh offered assistance if needed.
>
>
> Management over DTN Requirements
> ------------------------------------------------
> * We will probably need some protocol for global network management where the local network management distributes requested information or traps via bundles.
>
> * What are the purposes of DTN Network Management?
>  - Configuration
>  - Traffic and security policy
>  - Status and measurements
>
> * Network Management for a DTN may be useful to the routing decisions.  The routing decision may find it useful to have knowledge of:
>  - Power (Battery Life)
>  - Processing Power
>  - Transmission Capability (Convergence Layers, Bandwidth)
>  - Connectivity
>
>
>
> ******************************
> Will Ivancic
>
> _______________________________________________
> 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: Fri, 6 Feb 2009 15:03:04 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTN Network Management Meeting Notes January 21 and February 2, 2009

DTN Network Management - Collaborators
Meeting Notes for
Wednesday, January 21 and Monday February 2, 2009
1:00 - 2:00 EST (18:00 - 19:00 UTC)

A teleconference was held on Wednesday, January 21, 2009 due to Martin Luther King Day and the Inauguration.  Another very short teleconference was held Monday, February 2nd.  These notes are a combination of those two teleconferences.

The following teleconference will be, Monday, February 16, 2009.

Participants:
*	BBN - Cambridge
*	Hans Kruse, Shawn Ostermann  - Ohio University
*	Will Ivancic, Joseph Ishac, Wes Eddy - NASA Glenn
*	Scott Burleigh - NASA JPL
*	Ed Birrane and others   - Applied Physics Lab
*	Keith Scott - MITRE
*	Simon Perreault - Viagenie

Agenda 21-Jan-2009
==================
UAV scenario - description yet to be written down (Ivancic)

Open Discussion

Agenda 2-Feb-2009
=================
DTNRG is meeting March 19 and 20th at Google in Mountain View, California USA.  In addition, I believe Stephen requested 1 hour at IETF (San Francisco).
 - Agenda yet to be sent for the March 19-20.  
    -> We probably should request some time and topics.  
    -> Who is planning to attend IRTF DTNRG and IETF?

Available DTN Testbeds / DTN interconnected sites.  

General Discussion
-----------------------
* Scott Burleigh sent out a write up on the network management performed via DINET to the NASA internal group.  This has yet to be cleared for general release.

* Will Ivancic has not been able to make any progress on the Draft due to other priorities.  Work should commence with UAV scenario

* Short discussion on John Day's book, "Patterns in Network Architecture - A Return to Fundamentals"  regarding network management and the history around the decision to use SNMP versus High-Level Entity Management System (HEMS).   

* Discussion of RFC 1757, Remote Network Management Information Base
 - Need to rethink transport for DTN Network Management.
 - It may be wise to investigate RMON (Remote Monitoring) for Data Representation and other ideas.

* Ed Birrane of Applied Physics Labs (APL) set up a wiki for use by the network management team.  For the time being, access will be restricted via username/password. Instructions for access are in the list archive email of Jan 23 from Ed Birrane.

Available DTN Bundling/Forwarding Agents
-------------------------------------------------------
* Ohio University and Glenn Research are both considering establishing DTN bundle agent directories via wikis.   (As a result, Will Ivancic sent a request to Stephen Farrel and Kevin Fall suggesting that the DTNRG wiki be used for this purpose.  This would provide a single location instead of a multitude of wikis that need to be searched for information.  The proposal is currently under consideration.)

* Glenn Research Center has a DTN bundle agent up, but no hostname entry in the DNS yet.  That is being worked.  This bundle agent has both ION and DTN-2 implementations.  As soon as we decide which wiki the location capability information will reside in, we will update the wiki and send the information to the DTNRG group.

* Some discussion between GRC and Ohio University on getting ION bundle agents configured properly to pass bundles.  The configuration information should be on the Ohio University ION code distribution site.  Scott Burleigh offered assistance if needed. 

Management over DTN Requirements
------------------------------------------------
* We will probably need some protocol for global network management where the local network management distributes requested information or traps via bundles.

* What are the purposes of DTN Network Management?
 - Configuration
 - Traffic and security policy
 - Status and measurements
 
* Network Management for a DTN may be useful to the routing decisions.  The routing decision may find it useful to have knowledge of:
 - Power (Battery Life)
 - Processing Power
 - Transmission Capability (Convergence Layers, Bandwidth)
 - Connectivity

******************************
Will Ivancic

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 5 Feb 2009 11:30:25 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] March 19-20 Meeting

Regarding the DTNRG Meeting of March 19 and 20.

Not everybody can travel.  I will be on site, but others would probably like to participate remotely.

Will it be possible to make this meeting available to remote users either via teleconference or audio streaming/jabber or some combination?

Will

Date: Wed, 4 Feb 2009 11:48:25 +0000
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG  March 19-20 meeting

Hi Will,

I'll post an initial agenda & some logistics in the next few days.
In the meantime, folks who have a topic they'd like to see discussed
or who'd like a presentation slot can mail myself and Kevin,

Thanks,
Stephen.

Ivancic, William D. (GRC-RHN0) wrote:
> The following are the currently planned DTN meetings scheduled for March 2009:
> ==============================================================================
> 19 Mar 2009   (G-plex Mountain View)  (DTNRG)
> 20 Mar 2009   (G-plex Mountain View)  (DTNRG)
> 
> 
> I don't recall seeing a schedule for the DTNRG meeting.  This email is a request for a schedule.   Basically we are talking about two days of DTNRG discussion (with potentially and hour at IETF the following week).  In order to efficiently utilize the time of all parties to its fullest potential I think we should establish the goals of the DTNRG meeting and a corresponding agenda.
> 
> I suggest the following topics be included in the agenda:
> 
> DTNRG drafts
>  - What documents need to be completed and the status 
>  - I suspect this will also be covered at IETF in the hour session so maybe it isn't needed here.
> 
> Naming and Addressing and Routing
>  - Seems appropriate as IETF-74 may be having a BOF on Routing and Addressing in Next-Generation EnteRprises as well as one on Multiple Interfaces (MIF)
>  - Routing and multi-homed networks - particularly for cases where one might be connected to a space link on one side and an IP network on the other.
>  - Routing across domains such as across Autonomous Systems.
> 
> DTN Security
>  - Is there a need for a DTN security architecture specification?  Currently DTN BSP is just a mirror of ESP or AH for bundles rather than IP packets.  There hasn't appeared to be much discussion on filtering (DTN-Tables vs IP-Tables), policy such as only passing bundles for specific domains on, key management and distribution, etc...   It seems like much of DTN security would be aided by some type of hierarchical naming scheme.
> 
> Network Management
>  - Much discussion the network management splinter group suggests that network management and routing may be closely intertwined.  For example, in the DINET experiment the network management was used to distribute contact times and capabilities for use by the contact graph routing algorithm.  
> 
> Bringing Naming and Addressing, Routing, Security and Network Management together consider the following:  
> =========================================================
> Three DTN Autonomous Systems A,B and C.   
> Each with numerous nodes 1-N.  
> The route for A1 to A5 is:
> A1->A2->B3->C5->B1->C8->A5
> Interface A2/B3 is DTN over space link  CCSDS Advanced Orbiting System (AOS) protocol. 
> Interface B3/C5 is DTN over space link CCSDS proximity-1 protocol
> All other interfaces are DTN over IP.
> 
> How does one handle security, routing, naming an addressing for such a system?  Usually one does not hop in and out of Autonomous Systems, but for DTNs, that may not be the case.  Rather, it might be the normal mode of operations for some architectures.
> 
> 
> DTNbone
>  - Perhaps some face-to-face time can be used to integrate some of the DTN nodes together.
>  - Summary and description of applications that are DTN aware
>  - DTN application wish list.
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 03 Feb 2009 13:08:14 +0000
From: Elwyn Davies <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG  March 19-20 meeting
Reply-To: [email-masked]

Ivancic, William D. (GRC-RHN0) wrote:
> The following are the currently planned DTN meetings scheduled for March 2009:
> ==============================================================================
> 19 Mar 2009   (G-plex Mountain View)  (DTNRG)
> 20 Mar 2009   (G-plex Mountain View)  (DTNRG)
>
>
> I don't recall seeing a schedule for the DTNRG meeting.  This email is a request for a schedule.   Basically we are talking about two days of DTNRG discussion (with potentially and hour at IETF the following week).  In order to efficiently utilize the time of all parties to its fullest potential I think we should establish the goals of the DTNRG meeting and a corresponding agenda.
>
> I suggest the following topics be included in the agenda:
>
> DTNRG drafts
>  - What documents need to be completed and the status 
>   
Yes.. As I was asked to shepherd documents to be submtted to the IRSG I
would appreciate some time both in the meeting and outside it to see
where we area with authors.
>  - I suspect this will also be covered at IETF in the hour session so maybe it isn't needed here.
>   
As regards scheduling of the IETF session, I think I would appreciate
the session being close to the beginning of the IETf week as I am not
sure that I need to stay for the whole IETF week.

Regards,
Elwyn
> Naming and Addressing and Routing
>  - Seems appropriate as IETF-74 may be having a BOF on Routing and Addressing in Next-Generation EnteRprises as well as one on Multiple Interfaces (MIF)
>  - Routing and multi-homed networks - particularly for cases where one might be connected to a space link on one side and an IP network on the other.
>  - Routing across domains such as across Autonomous Systems.
>
> DTN Security
>  - Is there a need for a DTN security architecture specification?  Currently DTN BSP is just a mirror of ESP or AH for bundles rather than IP packets.  There hasn't appeared to be much discussion on filtering (DTN-Tables vs IP-Tables), policy such as only passing bundles for specific domains on, key management and distribution, etc...   It seems like much of DTN security would be aided by some type of hierarchical naming scheme.
>
> Network Management
>  - Much discussion the network management splinter group suggests that network management and routing may be closely intertwined.  For example, in the DINET experiment the network management was used to distribute contact times and capabilities for use by the contact graph routing algorithm.  
>
> Bringing Naming and Addressing, Routing, Security and Network Management together consider the following:  
> =========================================================
> Three DTN Autonomous Systems A,B and C.   
> Each with numerous nodes 1-N.  
> The route for A1 to A5 is:
> A1->A2->B3->C5->B1->C8->A5
> Interface A2/B3 is DTN over space link  CCSDS Advanced Orbiting System (AOS) protocol. 
> Interface B3/C5 is DTN over space link CCSDS proximity-1 protocol
> All other interfaces are DTN over IP.
>
> How does one handle security, routing, naming an addressing for such a system?  Usually one does not hop in and out of Autonomous Systems, but for DTNs, that may not be the case.  Rather, it might be the normal mode of operations for some architectures.
>
>
> DTNbone
>  - Perhaps some face-to-face time can be used to integrate some of the DTN nodes together.
>  - Summary and description of applications that are DTN aware
>  - DTN application wish list.
>
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic 
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

From: "Parikh, Salil" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 2 Feb 2009 22:01:30 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] delivery of bundle fragments

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

Can this part of the BP spec be relaxed to allow delivery of fragments?  An=
 API could offer applications the option of receiving fragments (along with=
 relevant metadata).

>From Section 3.1 of RFC 5050:

Delivery -  Upon reception, the processing of a bundle that has been
      sent to a given node depends on whether or not the receiving node
      is registered in the bundle's destination endpoint.  If it is, and
      if the payload of the bundle is non-fragmentary (possibly as a
      result of successful payload reassembly from fragmentary payloads,
      including the original payload of the received bundle), then the
      bundle is normally "delivered" to the node's application agent
      subject to the registration characterizing the node's membership
      in the destination endpoint.  ...

--_000_06CBA47B9C3FA7409BF459DAA035248902C15418DFIMCMBX3MITREO_
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:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/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/sharepoin=
t/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://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xm=
lns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D=
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schem=
as.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.mi=
crosoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsof=
t.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/=
package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats=
.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/off=
ice/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/=
2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpa=
ges" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/typ=
es" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/mess=
ages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibr=
ary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer=
/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: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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>Can
this part of the BP spec be relaxed to allow delivery of fragments?&nbsp; A=
n
API could offer applications the option of receiving fragments (along with =
relevant
metadata). <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>From
Section 3.1 of RFC 5050:<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>Delivery
-&nbsp; Upon reception, the processing of a bundle that has been<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sent to a given node depends on whether or not the receiving node<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is registered in the bundle's destination endpoint.&nbsp; If it is, and<o:p=
></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if the payload of the bundle is non-fragmentary (possibly as a<o:p></o:p></=
span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
result of successful payload reassembly from fragmentary payloads,<o:p></o:=
p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
including the original payload of the received bundle), then the<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bundle is normally &quot;delivered&quot; to the node's application agent<o:=
p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
subject to the registration characterizing the node's membership<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in the destination endpoint.&nbsp; ...<o:p></o:p></span></p>

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

</div>

</body>

</html>

--_000_06CBA47B9C3FA7409BF459DAA035248902C15418DFIMCMBX3MITREO_--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 2 Feb 2009 15:52:05 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTNRG  March 19-20 meeting

The following are the currently planned DTN meetings scheduled for March 2009:
==============================================================================
19 Mar 2009   (G-plex Mountain View)  (DTNRG)
20 Mar 2009   (G-plex Mountain View)  (DTNRG)

I don't recall seeing a schedule for the DTNRG meeting.  This email is a request for a schedule.   Basically we are talking about two days of DTNRG discussion (with potentially and hour at IETF the following week).  In order to efficiently utilize the time of all parties to its fullest potential I think we should establish the goals of the DTNRG meeting and a corresponding agenda.

I suggest the following topics be included in the agenda:

DTNRG drafts
 - What documents need to be completed and the status 
 - I suspect this will also be covered at IETF in the hour session so maybe it isn't needed here.

Naming and Addressing and Routing
 - Seems appropriate as IETF-74 may be having a BOF on Routing and Addressing in Next-Generation EnteRprises as well as one on Multiple Interfaces (MIF)
 - Routing and multi-homed networks - particularly for cases where one might be connected to a space link on one side and an IP network on the other.
 - Routing across domains such as across Autonomous Systems.

DTN Security
 - Is there a need for a DTN security architecture specification?  Currently DTN BSP is just a mirror of ESP or AH for bundles rather than IP packets.  There hasn't appeared to be much discussion on filtering (DTN-Tables vs IP-Tables), policy such as only passing bundles for specific domains on, key management and distribution, etc...   It seems like much of DTN security would be aided by some type of hierarchical naming scheme.

Network Management
 - Much discussion the network management splinter group suggests that network management and routing may be closely intertwined.  For example, in the DINET experiment the network management was used to distribute contact times and capabilities for use by the contact graph routing algorithm.  

Bringing Naming and Addressing, Routing, Security and Network Management together consider the following:  
=========================================================
Three DTN Autonomous Systems A,B and C.   
Each with numerous nodes 1-N.  
The route for A1 to A5 is:
A1->A2->B3->C5->B1->C8->A5
Interface A2/B3 is DTN over space link  CCSDS Advanced Orbiting System (AOS) protocol. 
Interface B3/C5 is DTN over space link CCSDS proximity-1 protocol
All other interfaces are DTN over IP.

How does one handle security, routing, naming an addressing for such a system?  Usually one does not hop in and out of Autonomous Systems, but for DTNs, that may not be the case.  Rather, it might be the normal mode of operations for some architectures.

DTNbone
 - Perhaps some face-to-face time can be used to integrate some of the DTN nodes together.
 - Summary and description of applications that are DTN aware
 - DTN application wish list.

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

From: "Symington, Susan F." <[email-masked]>
To: dtn interest <[email-masked]>
Date: Mon, 2 Feb 2009 15:26:26 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTN bundle diversion and encapsulatin I-Ds

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

DTN RG:

I just submitted two DTN I-Ds that are related to each other, DTN Bundle Di=
version (draft-irtf-dtnrg-bundle-divert-00) and DTN Bundle-in-Bundle Encaps=
ulation (draft-irtf-dtnrg-bundle-encapsulation-05).

As I discussed at the Minneapolis meeting, the Bundle Diversion draft enhan=
ces RFC 5050 by introducing two new concepts: bundle diversion and bundle i=
njection. "Diversion" is the act of a bundle protocol agent moving an entir=
e bundle from some point in bundle processing in the BPA to a DTN applicati=
on agent. This diversion of a bundle from the BPA to an application agent i=
s distinct from delivery of the bundle at that application agent.  "Injecti=
on" is the inverse of diversion. It is the act of an application agent movi=
ng an entire bundle from the application agent into some point in bundle pr=
ocessing in the BPA.  This injection of a bundle from an application agent =
to the BPA is distinct from bundle transmission. Diversion might take place=
, for example, at the entrance to an encapsulation tunnel and injection mig=
ht take place at the other end of that tunnel.

The Bundle-in-Bundle Encapsulation I-D now just defines the capability and =
format for placing one or more bundles inside of the payload field of an en=
capsulating bundle's Bundle Payload Block.

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC010CD704ADIMCMBX2MITREO_
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:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/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/sharepoin=
t/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://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xm=
lns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D=
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schem=
as.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.mi=
crosoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsof=
t.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/=
package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats=
.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/off=
ice/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/=
2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpa=
ges" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/typ=
es" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/mess=
ages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibr=
ary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer=
/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:10.5pt;
	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>

<p class=3DMsoNormal>DTN RG:<o:p></o:p></p>

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

<p class=3DMsoNormal>I just submitted two DTN I-Ds that are related to each=
 other,
DTN Bundle Diversion (draft-irtf-dtnrg-bundle-divert-00) and DTN
Bundle-in-Bundle Encapsulation (draft-irtf-dtnrg-bundle-encapsulation-05).<=
o:p></o:p></p>

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

<p class=3DMsoNormal>As I discussed at the Minneapolis meeting, the Bundle
Diversion draft enhances RFC 5050 by introducing two new concepts: bundle
diversion and bundle injection. &quot;Diversion&#8221; is the act of a bund=
le
protocol agent moving an entire bundle from some point in bundle processing=
 in
the BPA to a DTN application agent. This diversion of a bundle from the BPA=
 to
an application agent is distinct from delivery of the bundle at that
application agent.&nbsp; &#8220;Injection&#8221; is the inverse of diversio=
n.
It is the act of an application agent moving an entire bundle from the
application agent into some point in bundle processing in the BPA.&nbsp; Th=
is
injection of a bundle from an application agent to the BPA is distinct from
bundle transmission. Diversion might take place, for example, at the entran=
ce
to an encapsulation tunnel and injection might take place at the other end =
of
that tunnel.<o:p></o:p></p>

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

<p class=3DMsoNormal>The Bundle-in-Bundle Encapsulation I-D now just define=
s the
capability and format for placing one or more bundles inside of the payload
field of an encapsulating bundle's Bundle Payload Block.<o:p></o:p></p>

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

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>-susan<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
**</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>Susan
Symington</span><span style=3D'font-size:12.0pt;font-family:"Times New Roma=
n","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>The
MITRE Corporation</span><span style=3D'font-size:12.0pt;font-family:"Times =
New Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>[email-masked]</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7209
(voice)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman"=
,"serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7142
(fax)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman","=
serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
***</span><o:p></o:p></p>

</div>

</body>

</html>

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC010CD704ADIMCMBX2MITREO_--

Date: Mon, 02 Feb 2009 12:03:52 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] Call for Papers: MobiArch 2009 (co-located with ACM MobiSys)

                         Call for Papers

          The 4th ACM International Workshop on Mobility
       in the Evolving Internet Architecture (MobiArch 2009)
       -----------------------------------------------------

      Co-located with MobiSys, 22 June 2009, Krakow, Poland
     http://user.informatik.uni-goettingen.de/~mobiarch/2009/

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, multi-homing,
security, wireless access 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. For instance, an appropriate system that allows communicating
with a mobile host requires addressing several fundamental issues with
the Internet architecture, such as ability to locate the mobile
host/service, preserving ongoing communications upon changes of
locations, as well as efficient and secure handover management. As
another example, the emerging wireless technologies may pose additional
challenges to the Internet architecture since they introduce design
principles different from the original Internet.

MobiArch 2009 welcomes submissions, from both researchers and
practitioners, in exploration of recent advances in architectures,
protocols, and experiences with emerging technologies on various
mobility issues 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 modelling, multi-homing, security,
architectural impacts and deployment considerations. Furthermore, the
potential of usability of mobility services for connecting people and
devices in developing regions of the world into the Internet
infrastructure will be also explored.

Topics of MobiArch 2009 cover all aspects of architectural issues and
system support for mobility in the Internet, including but not limited to:

* Impacts of new wireless technologies/services, networking
   technologies, 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, routing, locator/identifier split, multi-homing
   and load sharing issues
* Security and privacy issues in mobility networks and impacts to
   Internet architecture
* Architectures and mechanisms for wireless/mobile connectivity in
   extreme environments (e.g., remote areas, developing countries)
* Performance issues with mobility in the Internet
* QoS and middlebox issues in mobility networks and impacts to Internet
   architecture
* Economic and deployment issues of mobility solutions (infrastructure
   and devices)
* Impact of social aspects on mobility architectures, mobile application
   and protocol design
* Technologies for mobile wireless access and interactions

Submissions must present original results. Selected papers will be
forward-looking, describe their relationship to existing work, and have
impact and implications for ongoing or future research.
Submitted papers must be no more than 6 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. All paper submission
will be handled via EDAS (http://edas.info/7188). Papers will be
reviewed single blind.

Important Dates:

     Submission Deadline:      22 February 2009
     Acceptance Notification:  31 March 2009
     Camera Ready Due:         15 April 2009
     Workshop Date:            22 June 2009

TPC Chairs:

     Joerg Ott   Helsinki University of Technology (TKK)
     Kun Tan     Microsoft Research Asia

For more information, contact workshop co-chairs at
[email-masked].