Subject: Re: [dtn-interest] dtn-interest -- confirmation of subscription -- request 822424
From: Adam Przybyla <[email-masked]>
To: Loïc Maître <[email-masked]>
Cc: [email-masked]
Date: Sat, 13 May 2006 19:36:20 +0200 (CEST)
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

On Sat, 13 May 2006, [ISO-8859-1] Lo?c Maître wrote:

>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Sat, 13 May 2006 18:33:30 +0200
From: =?ISO-8859-1?Q?Lo=EFc_Ma=EEtre?= <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] dtn-interest -- confirmation of subscription -- request 822424
Sender: [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 12 May 2006 21:42:28 -0700
From: "Fall, Kevin" <[email-masked]>
To: "DTN" <[email-masked]>
Subject: [dtn-interest] link of some interest
Sender: [email-masked]

Fyi -- I just became aware of the following related work:

http://www.ee.technion.ac.il/Sites/People/ArielOrda/Info/JournalPublicat
ions.html

Note the "time dependent edge length" paper...

Also, this one:

http://www.it.iitb.ac.in/~it612/resources/repository/INFOCOM2002/The_tra
velling_miser_problem__.pdf

This is the "travelling miser" problem.  The motivation isn't exactly
what we are lookin for, but there are at least some overlapping ideas.

Cheers,
- K

Date: Fri, 12 May 2006 10:45:25 -0700
From: Michael Demmer <[email-masked]>
To: ?? ???? <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN2 comiling problem
Mail-Followup-To: ?? ???? <[email-masked]>, [email-masked]
Sender: [email-masked]

first of all, for questions related to the reference implementation,
you should use the dtn-users mailing list.

as per your specific question, i've checked in a change to the latest
cvs version that fixes the problem you pointed out, so if you update
to that, you should be all set.

-mike

From: =?gb2312?B?1cUg1emyqQ==?= <[email-masked]>
To: [email-masked]
Date: Fri, 12 May 2006 20:19:11 +0800
Subject: [dtn-interest] DTN2 comiling problem
Sender: [email-masked]

<html><div style='background-color:'><DIV class=RTE>
<P><BR><BR>hello,</P>
<P>i try to compile and install the DTN2 on my computer(windows 
xp)&nbsp;which is installed with cygwin. Unfortunately, when i running 
"make", i get this kind of error information : </P>
<P>make[1]: Entering directory `/home/user/DTN2/daemon'<BR>g++ -I.. 
-I../servlib&nbsp;&nbsp; -I/usr/local/BerkeleyDB.4.3/include&nbsp; -g 
-fno-inline&nbsp; -MM<BR>D -MP -MT "dtnd.o dtnd.E dtnd.po" -Wall 
-Werror&nbsp; -c dtnd.cc -o dtnd.o<BR>g++ dtnd.o ../version.c 
../applib/libdtnapisrv.a ../servlib/libdtnserv.a 
../oasy<BR>s/liboasys.a&nbsp; -o dtnd -L/usr/local/BerkeleyDB.4.3/lib&nbsp; 
-ltcl -ldb_cxx-4.3<BR>../applib/libdtnapisrv.a(APIServer.o): In function 
`_ZN3dtn9APIServerC2Ev':<BR>/home/user/DTN2/applib/APIServer.cc:127: 
undefined reference to 
`_xdrmem_create'<BR>/home/user/DTN2/applib/APIServer.cc:128: undefined 
reference to `_xdrmem_create'<BR>../applib/libdtnapisrv.a(APIServer.o): In 
function 
`_ZN3dtn9APIServerC1Ev':<BR>/home/user/DTN2/applib/APIServer.cc:127: 
undefined reference to 
`_xdrmem_create'<BR>/home/user/DTN2/applib/APIServer.cc:128: undefined 
reference to `_xdrmem_create'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): 
In function `xdr_DTN_STATUS':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:87: 
undefined reference to 
`_xdr_int'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_tuple_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:114: undefined 
reference to `_xdr_char'<BR>/home/user/DTN2/applib/dtn_types_xdr.c:114: 
undefined reference to 
`_xdr_vector'<BR>/home/user/DTN2/applib/dtn_types_xdr.c:117: undefined 
reference to `_xdr_bytes'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In 
function 
`xdr_dtn_info_request_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:134: 
undefined reference to 
`_xdr_enum'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_inforeq_interfac<BR>es_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:147: 
undefined reference to 
`_xdr_vector'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_reg_id_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:185: 
undefined reference to 
`_xdr_u_int'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_timeval_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:199: 
undefined reference to 
`_xdr_u_int'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_reg_action_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:222: 
undefined reference to 
`_xdr_enum'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_reg_info_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:244: 
undefined reference to 
`_xdr_bytes'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_bundle_priority_<BR>t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:262: 
undefined reference to 
`_xdr_enum'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_bundle_delivery_<BR>opts_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:285: 
undefined reference to 
`_xdr_enum'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_bundle_spec_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:307: 
undefined reference to 
`_xdr_int'<BR>/home/user/DTN2/applib/dtn_types_xdr.c:309: undefined 
reference to `_xdr_int'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In 
function 
`xdr_dtn_bundle_payload_l<BR>ocation_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:328: 
undefined reference to 
`_xdr_enum'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In function 
`xdr_dtn_bundle_payload_t<BR>':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:342: 
undefined reference to 
`_xdr_bytes'<BR>/home/user/DTN2/applib/dtn_types_xdr.c:346: undefined 
reference to `_xdr_bytes'<BR>../applib/libdtnapisrv.a(dtn_types_xdr.o): In 
function 
`xdr_dtn_bundle_auth_t':<BR>/home/user/DTN2/applib/dtn_types_xdr.c:364: 
undefined reference to `_xdr_bytes'<BR>collect2: ld returned 1 exit 
status<BR>make[1]: *** [dtnd] Error 1<BR>make[1]: Leaving directory 
`/home/user/DTN2/daemon'<BR>make: *** [daemon] Error 2<BR></P>
<P>I have installed sunrpc already and berkeley db4.2, however, it seems 
the "make" can not link to the rpc.h. Is there somebody have installed DTN2 
by cygwin or happens to encounter this kind of problem? Any help will be 
greatly appreciated.</P>
<P>Thanks!!!</P>
<P>best regards</P>
<P>frankie</P>
<P>&nbsp;</P></DIV></div></html>

To: [email-masked]
From: Brian Levine <[email-masked]>
Date: Thu, 11 May 2006 10:41:11 -0400
Subject: [dtn-interest] mobile systems/DTN/mesh postdoc needed
Sender: [email-masked]

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

Our lab is currently looking for a postdoctoral research assistant to  
work in the areas of Mobile Networking, Disruption Tolerant  
Networking, Energy Management, Vehicular Networking, and Mesh  
Networking. The position will be for one and a half years starting  
during the summer of 2006, with possible extensions based on future  
funding. We are looking for applicants with high level of experience  
in systems building research and a strong research record.

More about our activities are listed within these two URLs:

http://prisms.cs.umass.edu
http://prisms.cs.umass.edu/diesel

We are soliciting applications through UMass Computer Science's open  
call for Postdoctoral Research Associates (R24998). Apply through the  
open call and also email Mark Corner ([email-masked]) and Brian  
Levine ([email-masked]) to let us know that you have applied. If  
you have already applied through our regular procedures, send us an  
email and we will review your application. We are expecting to make a  
decision in a short time frame (by June 2006).

Brian Levine and Mark Corner
UMass Amherst
--Apple-Mail-3--599936232
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-3--599936232--

Date: Mon, 08 May 2006 08:20:32 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] [Fwd: Re: irtf review of dtn arch]
Sender: [email-masked]

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

Here's our second (and last) irsg review of the arch
document.

Couple of good comments and some more nits for auth-48 or
earlier. Again, no show stoppers (IMO) which is good.

Stephen.

--------------090408000208010406070106
Content-Type: message/rfc822;
 name="Re: irtf review of dtn arch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: irtf review of dtn arch"

From: Avri Doria <[email-masked]>
Subject: Re: irtf review of dtn arch
Date: Mon, 8 May 2006 01:57:11 -0400
To: Stephen Farrell <[email-masked]>

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

Hi,

Not sure exactly how i am supposed to submit this.

a.

--Apple-Mail-1--890576484
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	x-unix-mode=0644;
	x-mac-creator=454D4178;
	name="review_draft-irtf-dtng-arch-05_avri.txt"
Content-Disposition: attachment;
	filename=review_draft-irtf-dtng-arch-05_avri.txt

IRSG Review

Document: Delay-Tolerant Network Architecture
Date: 8 May, 2006
Reviewer: Avri Doria

Status: I wasn't clear on whether this is being considered for
experimental or informational?  In general i think it is more
apporpriate for informational.

I think the document is essentially read to be published.  I have made
some comments below, but none of them are show stoppers.

---

Page 5

 - provide security mechanisms that protect the infrastructure from 
    unauthorized use by discarding traffic as quickly as possible 

One of the security issues that also needs to be dealt with is making
sure that a malicious user does not casue authorized traffice to be
removed too quickly.  Perhaps it only needs to be specific about what
traffic is quickly discarded. 

Page 6, in section 3.1

It appears that 'message' is being used in two sense in this
paragraph. first in therms of the ADU, and later in terms of message
oriented abstractions for the underlying network.  It might help to
divide the section into tow sections - one that descirbes bundles and
one that describe the preference for message-passing or
stream-oriented. 

In the third para.  the last line says: 
  etc., and that stored messages will survive 
  system restarts.  

should this be stored 'bundles'.

I know this mau be picky but, in introducing a new concept it may be
best to be consistent in the use of language.

Page 20 2.14  Security

I think that the security section is somewhat one side.  One of the
security concerns I have with DTN when using acks and custodian
option, is a form of DOS that instead of using congestion, is able to
stop traffic with false acks and custodian acceptance before bundles
have been received.  I am also concerend about effect of spoofed
administrative records and bubndle custody signals.

Page 25.  Section 8

I think the security section might be a bit light and should list the
risks that are beleived to exist, even if they are discussed at length
elsewhere.  (BTW, the reference is wrong - should be 3.14) 

Also you might want to make reference to section 3.6.1 that make
reference to security modes and to 4.4 on security related state.

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

On 5 maj 2006, at 10.34, Stephen Farrell wrote:

>
> Great, thanks,
> S.
>
> Avri Doria wrote:
>> not yet.  will try to do so this weekend.
>> a.
>> On 5 maj 2006, at 07.11, Stephen Farrell wrote:
>>>
>>> Hi Avri,
>>>
>>> Avri Doria wrote:
>>>> hi Stephan,
>>>> don't know whether i am sufficiently impartial, but if you don't  
>>>> have enough volunteers, you can include me.
>>>
>>> I'm trying to feel my way through being a shepherd...
>>>
>>> Did you post that review?
>>>
>>> Ta,
>>> Stephen.
>>>
>>>
>
>

--Apple-Mail-1--890576484--

--------------090408000208010406070106--

Date: Sat, 6 May 2006 09:56:16 +0200
From: "Alessandro Berni" <[email-masked]>
To: "Mirco Musolesi" <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Cc: DTN <[email-masked]>
Sender: [email-masked]

------=_Part_23025_8656140.1146902176391
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 5/6/06, Mirco Musolesi <[email-masked]> wrote:

>
> > I guess I don't know since we never discussed it;-) If
> > a mail address is good enough, you can use a mailto: URI
> > so probably that's what most people would do, but other
> > URIs might work too, (ldap:, tel:, ...)
>
> It seems to me that another interesting aspect is that a specific
> person may be reachable through various types of network interfaces
> (i.e., email, Bluetooth, etc).
>
> An interesting problem may be the mapping between a specific person
> and his/her potentially multiple URIs. In other words, it may be
> useful to define a collection of URIs for a single person/host.

I would recommend that you check out the ideas behind the Handle System (RF=
C
3650, 3651, 3652), a general purpose naming system which can be used to
develop URN/URI schemes.

As an example, one existing large-scale implementation of the Handle system
is the Digital Object Identifier (DOI) System (www.doi.org), used by
publishers to provide persistent identification to electronic objects
("publications"). Every digital object can be associated to different
"content types" for dissemination, as in the case of a book that is made
available in .pdf, .txt, .doc format. All those different formats are
indexed inside the digital object (handle, "doi:", URI, ...) that identifie=
s
a specific book. An overview of the system is provided in
http://www.doi.org/topics/HS_overview_slides.ppt

By analogy, the DTN handle ("dtn:") for a specific person could embed
different "data types" or "URIs", to identify various connectivity options =
(
i.e. email, Bluetooth, etc.): that would provide the required mapping
between a specific person and his/her multiple URIs.

-- Alessandro

------=_Part_23025_8656140.1146902176391
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>&nbsp;</div>
<div><span class=3D"gmail_quote">On 5/6/06, <b class=3D"gmail_sendername">M=
irco Musolesi</b> &lt;<a href=3D"mailto:[email-masked]">m.musolesi=
@cs.ucl.ac.uk</a>&gt; wrote:</span></div>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>&gt; I guess I don't know si=
nce we never discussed it;-) If<br>&gt; a mail address is good enough, you =
can use a mailto: URI
<br>&gt; so probably that's what most people would do, but other<br>&gt; UR=
Is might work too, (ldap:, tel:, ...)<br><br>It seems to me that another in=
teresting aspect is that a specific<br>person may be reachable through vari=
ous types of network interfaces
<br>(i.e., email, Bluetooth, etc).<br><br>An interesting problem may be the=
 mapping between a specific person<br>and his/her potentially multiple URIs=
. In other words, it may be<br>useful to define a collection of URIs for a =
single person/host.
</blockquote>
<div>&nbsp;</div>
<div>I would recommend that you check out the ideas behind the Handle Syste=
m (RFC 3650, 3651, 3652), a general purpose naming system which can be used=
 to develop URN/URI schemes. </div>
<div>&nbsp;</div>
<div>As an example, one existing large-scale implementation of the Handle s=
ystem is the Digital Object Identifier (DOI) System (<a href=3D"http://www.=
doi.org">www.doi.org</a>), used by publishers to provide persistent identif=
ication to electronic objects (&quot;publications&quot;). Every digital obj=
ect can be associated to different &quot;content types&quot;&nbsp;for disse=
mination, as in the case of a book that is made available in .pdf, .txt, .d=
oc format. All those different formats are indexed inside the digital objec=
t (handle, &quot;doi:&quot;, URI, ...) that identifies a specific book. An =
overview of the system is provided in=20
<a href=3D"http://www.doi.org/topics/HS_overview_slides.ppt">http://www.doi=
.org/topics/HS_overview_slides.ppt</a></div>
<div>&nbsp;</div>
<div>By analogy, the DTN handle (&quot;dtn:&quot;)&nbsp;for a specific pers=
on could embed different &quot;data types&quot; or &quot;URIs&quot;, to ide=
ntify various connectivity options (i.e. email, Bluetooth, etc.): that woul=
d provide the required mapping between a specific person and his/her multip=
le URIs.
</div>
<div>&nbsp;</div>
<div>-- Alessandro</div>
<div>&nbsp;</div>

------=_Part_23025_8656140.1146902176391--

Cc: Jeff Wilson <[email-masked]>, DTN <[email-masked]>
From: Mirco Musolesi <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Date: Fri, 5 May 2006 23:49:50 +0100
To: Stephen Farrell <[email-masked]>
Sender: [email-masked]

> I guess I don't know since we never discussed it;-) If
> a mail address is good enough, you can use a mailto: URI
> so probably that's what most people would do, but other
> URIs might work too, (ldap:, tel:, ...)

It seems to me that another interesting aspect is that a specific  
person may be reachable through various types of network interfaces  
(i.e., email, Bluetooth, etc).

An interesting problem may be the mapping between a specific person  
and his/her potentially multiple URIs. In other words, it may be  
useful to define a collection of URIs for a single person/host.

Mirco

--
Mirco Musolesi
Dept. of Computer Science, University College London
Gower Street London WC1E 6BT United Kingdom
Phone: +44 20 7679 0391 Fax: +44 20 7387 1397
Web: http://www.cs.ucl.ac.uk/staff/m.musolesi

Date: Fri, 05 May 2006 15:26:15 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Sender: [email-masked]

Stephen Farrell wrote:

>
>
> Scott Burleigh wrote:
>
>> On this point: back in early April I suggested that -- given how much 
>> fun we're having getting dtn: provisionally registered -- we might be 
>> better off registering "dtn" as an *alternative scheme tree name* 
>> rather than just the name of a single scheme on the IETF scheme 
>> tree.  That would enable us to generate new schemes ourselves as 
>> needed, which I think might be very helpful.  If we've only got one 
>> scheme to work with, we will end up spending a lot of time arguing 
>> over its definition and agreeing finally on a definition that either 
>> doesn't address everybody's concerns or else is excessively complex 
>> (so that it can address everybody's concerns) -- or, more likely, 
>> both.  But if each research interest can easily define its own 
>> scheme, which suits its own purposes, then research can proceed in 
>> parallel and nobody's interests have to be compromised.  
>> Implementations would have to support multiple scheme definitions to 
>> enable interoperability, but I strongly suspect that this would be 
>> less work than building support for an all-singing, all-dancing, 
>> suits-everybody-and-always-will scheme definition into every 
>> implementation, and updating that support every time we update the 
>> scheme definition to accommodate some situation we never anticipated.
>
>
> Scheme trees are what rfc 4395 talks about in the intro right?
> Quoting:
>
>    RFC 2717 defined a set of registration trees in which URI schemes
>    could be registered, one of which was called the IETF Tree, to be
>    managed by IANA.  RFC 2717 proposed that additional registration
>    trees might be approved by the IESG.  However, no such registration
>    trees have been approved.
>
>    This document eliminates RFC 2717's distinction between different
>    'trees' for URI schemes; instead there is a single namespace for
>    registered values.  Within that namespace, there are values that are
>    approved as meeting a set of criteria for URI schemes.  Other scheme
>    names may also be registered provisionally, without necessarily
>    meeting those criteria.
>
> The IANA list is at [1].
>
> Apparently there was a way to have a scheme like dtn.cbhe: but
> that's been deprecated I'm told. Would have suited us I think
> if it were still an option.

This is unfortunate.  I was going by RFC 2717, which is the governing 
document cited in the Bundle Protocol spec.  If that RFC is superseded 
then I guess this option is off the table.  Too bad.

Scott

Date: Fri, 05 May 2006 22:49:21 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Sender: [email-masked]

Scott Burleigh wrote:

> On this point: back in early April I suggested that -- given how much 
> fun we're having getting dtn: provisionally registered -- we might be 
> better off registering "dtn" as an *alternative scheme tree name* rather 
> than just the name of a single scheme on the IETF scheme tree.  That 
> would enable us to generate new schemes ourselves as needed, which I 
> think might be very helpful.  If we've only got one scheme to work with, 
> we will end up spending a lot of time arguing over its definition and 
> agreeing finally on a definition that either doesn't address everybody's 
> concerns or else is excessively complex (so that it can address 
> everybody's concerns) -- or, more likely, both.  But if each research 
> interest can easily define its own scheme, which suits its own purposes, 
> then research can proceed in parallel and nobody's interests have to be 
> compromised.  Implementations would have to support multiple scheme 
> definitions to enable interoperability, but I strongly suspect that this 
> would be less work than building support for an all-singing, 
> all-dancing, suits-everybody-and-always-will scheme definition into 
> every implementation, and updating that support every time we update the 
> scheme definition to accommodate some situation we never anticipated.

Scheme trees are what rfc 4395 talks about in the intro right?
Quoting:

    RFC 2717 defined a set of registration trees in which URI schemes
    could be registered, one of which was called the IETF Tree, to be
    managed by IANA.  RFC 2717 proposed that additional registration
    trees might be approved by the IESG.  However, no such registration
    trees have been approved.

    This document eliminates RFC 2717's distinction between different
    'trees' for URI schemes; instead there is a single namespace for
    registered values.  Within that namespace, there are values that are
    approved as meeting a set of criteria for URI schemes.  Other scheme
    names may also be registered provisionally, without necessarily
    meeting those criteria.

The IANA list is at [1].

Apparently there was a way to have a scheme like dtn.cbhe: but
that's been deprecated I'm told. Would have suited us I think
if it were still an option.

To me it looks like we want something like dtn://cbhe/foo or
maybe better dtn://cbhe.nasa.gov/foo or something, but this is
starting to sound familiar...

S.

[1] http://www.iana.org/assignments/uri-schemes.html

Date: Fri, 05 May 2006 14:05:35 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Sender: [email-masked]

Stephen Farrell wrote:

> Wes,
>
> Wesley Eddy wrote:
>
>> Is the "dtn://" URI scheme defined anywhere?  I see what the DTN2 RI
>> does to generate EIDs, but I don't see this behavior or any rules
>> described in the current arch or bp drafts.  Maybe I'm just missing
>> them, though.
>>
>> I think a previous version of the bp spec defined how they worked in the
>> old region setup, but I don't recall seeing standards-like text for the
>> new naming scheme.
>
> As I recall it, we were getting into kind of religious discussion
> about what's a good URI so the bundle protocol only includes
> mention of dtn:none and we punted on the rest.
>
> Anyone want to step up and write up a fuller description?
>
> S.
>
> PS: I'm in the process of getting dtn: registered as a provisional
> URI scheme, so if someone wanted to take this on in the near term,
> that'd probably help the registration along (its not a simple matter
> of no-one else having asked;-)

On this point: back in early April I suggested that -- given how much 
fun we're having getting dtn: provisionally registered -- we might be 
better off registering "dtn" as an *alternative scheme tree name* rather 
than just the name of a single scheme on the IETF scheme tree.  That 
would enable us to generate new schemes ourselves as needed, which I 
think might be very helpful.  If we've only got one scheme to work with, 
we will end up spending a lot of time arguing over its definition and 
agreeing finally on a definition that either doesn't address everybody's 
concerns or else is excessively complex (so that it can address 
everybody's concerns) -- or, more likely, both.  But if each research 
interest can easily define its own scheme, which suits its own purposes, 
then research can proceed in parallel and nobody's interests have to be 
compromised.  Implementations would have to support multiple scheme 
definitions to enable interoperability, but I strongly suspect that this 
would be less work than building support for an all-singing, 
all-dancing, suits-everybody-and-always-will scheme definition into 
every implementation, and updating that support every time we update the 
scheme definition to accommodate some situation we never anticipated.

Scott

Date: Fri, 05 May 2006 21:38:43 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Sender: [email-masked]

Wes,

Wesley Eddy wrote:
> Is the "dtn://" URI scheme defined anywhere?  I see what the DTN2 RI
> does to generate EIDs, but I don't see this behavior or any rules
> described in the current arch or bp drafts.  Maybe I'm just missing
> them, though.
> 
> I think a previous version of the bp spec defined how they worked in the
> old region setup, but I don't recall seeing standards-like text for the
> new naming scheme.

As I recall it, we were getting into kind of religious discussion
about what's a good URI so the bundle protocol only includes
mention of dtn:none and we punted on the rest.

Anyone want to step up and write up a fuller description?

S.

PS: I'm in the process of getting dtn: registered as a provisional
URI scheme, so if someone wanted to take this on in the near term,
that'd probably help the registration along (its not a simple matter
of no-one else having asked;-)

Date: Fri, 5 May 2006 15:55:00 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Reply-To: [email-masked]
Sender: [email-masked]

On Fri, May 05, 2006 at 08:34:14PM +0100, Stephen Farrell wrote:
> 
> I agree with the above. I interpreted the question more to be about
> how to reference a person using an EID rather than about encoding
> (though we cannot encode people's names in dtn: URIs), so the answer
> was speculating about how you might pick a URI to refer to a person
> ("this bundle is for Scott, wherever he is, however long it takes to
> get it to him").
> S.
>

Is the "dtn://" URI scheme defined anywhere?  I see what the DTN2 RI
does to generate EIDs, but I don't see this behavior or any rules
described in the current arch or bp drafts.  Maybe I'm just missing
them, though.

I think a previous version of the bp spec defined how they worked in the
old region setup, but I don't recall seeing standards-like text for the
new naming scheme.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Fri, 05 May 2006 20:34:14 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Sender: [email-masked]

Scott Burleigh wrote:
> Stephen Farrell wrote:
> 
>> Jeff Wilson wrote:
>>
>>>> ... with the
>>>> consensus ending up with URIs on the basis that EIDs are
>>>> not meant for people which was IMO a fair point.
>>>
>>> Are you saying that EID specifies a host?  How then does DTN address a
>>> specific person?
>>>
>>> Sorry to veer off topic, I'm just curious.
>>
>> I guess I don't know since we never discussed it;-) If
>> a mail address is good enough, you can use a mailto: URI
>> so probably that's what most people would do, but other
>> URIs might work too, (ldap:, tel:, ...)
> 
> I thought what was meant here was that EIDs as discussed in the 
> architecture document are what would appear in bundle headers and would 
> be exposed to the implementation of the bundle protocol, but they're not 
> necessarily what would be exposed to human users.  The API to a bundle 
> protocol implementation -- or the user interface to a BP-enabled 
> application --  might translate between ASCII and non-ASCII EIDs for the 
> convenience of the user, but what would travel over the wire or R/F 
> would be in ASCII representation.
> 
> An EID doesn't necessarily specify a host, or a person, or any 
> particular entity at all; it signifies whatever the scheme owner says it 
> signifies.  Mainly it's just a conceptual locus at which bundles may be 
> delivered to whomever they're supposed to be delivered to.

I agree with the above. I interpreted the question more to be about
how to reference a person using an EID rather than about encoding
(though we cannot encode people's names in dtn: URIs), so the answer
was speculating about how you might pick a URI to refer to a person
("this bundle is for Scott, wherever he is, however long it takes to
get it to him").
S.

Date: Fri, 05 May 2006 12:17:01 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Sender: [email-masked]

Stephen Farrell wrote:

> Jeff Wilson wrote:
>
>>> ... with the
>>> consensus ending up with URIs on the basis that EIDs are
>>> not meant for people which was IMO a fair point.
>>
>> Are you saying that EID specifies a host?  How then does DTN address a
>> specific person?
>>
>> Sorry to veer off topic, I'm just curious.
>
> I guess I don't know since we never discussed it;-) If
> a mail address is good enough, you can use a mailto: URI
> so probably that's what most people would do, but other
> URIs might work too, (ldap:, tel:, ...)

I thought what was meant here was that EIDs as discussed in the 
architecture document are what would appear in bundle headers and would 
be exposed to the implementation of the bundle protocol, but they're not 
necessarily what would be exposed to human users.  The API to a bundle 
protocol implementation -- or the user interface to a BP-enabled 
application --  might translate between ASCII and non-ASCII EIDs for the 
convenience of the user, but what would travel over the wire or R/F 
would be in ASCII representation.

An EID doesn't necessarily specify a host, or a person, or any 
particular entity at all; it signifies whatever the scheme owner says it 
signifies.  Mainly it's just a conceptual locus at which bundles may be 
delivered to whomever they're supposed to be delivered to.

Scott

Date: Fri, 05 May 2006 18:12:35 +0100
From: Stephen Farrell <[email-masked]>
To: Jeff Wilson <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] people addresses (was Re: Review of arch-05...)
Sender: [email-masked]

Jeff Wilson wrote:
>> ... with the
>> consensus ending up with URIs on the basis that EIDs are
>> not meant for people which was IMO a fair point.
> 
> Are you saying that EID specifies a host?  How then does DTN address a
> specific person?
> 
> Sorry to veer off topic, I'm just curious.

I guess I don't know since we never discussed it;-) If
a mail address is good enough, you can use a mailto: URI
so probably that's what most people would do, but other
URIs might work too, (ldap:, tel:, ...)

S.

Date: Fri, 5 May 2006 11:52:49 -0500
From: "Jeff Wilson" <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] people addresses (was Re: Review of arch-05...)
Sender: [email-masked]

> ... with the
> consensus ending up with URIs on the basis that EIDs are
> not meant for people which was IMO a fair point.

Are you saying that EID specifies a host?  How then does DTN address a
specific person?

Sorry to veer off topic, I'm just curious.

     thanks,
      jw

Date: Fri, 05 May 2006 15:40:41 +0100
From: Stephen Farrell <[email-masked]>
To: "Fall, Kevin" <[email-masked]>
CC: DTN <[email-masked]>, Andrei Gurtov <[email-masked]>
Subject: Re: [dtn-interest] Review of arch-05...
Sender: [email-masked]

Tend to agree with you there. Only thing I'd add though is
that I do recall some discussion of IRIs vs. URIs with the
consensus ending up with URIs on the basis that EIDs are
not meant for people which was IMO a fair point.

(Actually, at the time I argued for IRIs, but I might
now reverse that position on the basis of the problems
with Unicode and comparisons/c14n that are becoming
more and more apparent. [1])

S.

[1] http://www.unicode.org/reports/tr36/

Fall, Kevin wrote:
> Hi.  I think I'm basically comfortable with the document as-is.  The
> nits, I believe, we can change during the "here's your last chance to
> make editorial changes" portion from the rfc-editor before the final RFC
> number is assigned, and I'm willing to do that.
> 
> With respect to the other items (non-nits), here is what I think:
> 
> 1. congestion control -- still an ongoing bit of work in DTN.  There are
> some papers beginning to address it, but we don't have a total solution
> yet so I'm ok saying so in the draft
> 
> 2. the identity and locations are separated (or at least are not overtly
> linked in any real way-- the id's are URI's, not URL's.).  The
> architecture document is careful to say very little about how you
> actually arrange your routing and it treats the id's more like strings
> than anything else.
> 
> 3. non-ascii URIs.. hmm.  Well, I guess I'd say that if we really are
> beginning to have widespread success we can do that.  For now, I don't
> think anybody is actually working on non-ascii URI's in DTN, and to put
> them in there at this point I think might cause people to think we are
> really doing it when we aren't.  I don't have any particular objection
> to such things, however, so I could imagine a future document describing
> other forms and encodings for URIs.
> 
> Cheers
> - K
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-interest-
>> [email-masked]] On Behalf Of Stephen Farrell
>> Sent: Friday, May 05, 2006 7:19 AM
>> To: DTN
>> Cc: Andrei Gurtov
>> Subject: [dtn-interest] Review of arch-05...
>>
>>
>> Hi all, but mainly authors of the arch-05,
>>
>> Andrei Gurtov kindly did a review of this document as part
>> of the process of getting it to be an RFC. His review is
>> below.
>>
>> Do the authors want to make any changes as a result of
>> this? (Note: The process here doesn't require that we
>> satisfy the reviewer, but if is of course better to
>> fix/improve things where one can...)
>>
>> Stephen.
>>
>> Andrei's review:
>>
>> Below please find my review of the DTNRG arch draft.
>> The draft is of high quality and ready to go if the authors believe
> so.
>> Though it would be interesting to discuss following issues:
>>
>> - details of congestion control in DTNs is missing from the
>> architecture. Is it a feature that can be safely added afterwards or
>> should it be considered right from the beginning?
>> It would be interesting to consider e.g interactions between
> expiration
>> losses and congestion response at end points.
>> http://portal.acm.org/citation.cfm?id=965738
>>
>> - does the architecture support mobility and multihoming well. Should
>> the identity and locators be separated in the architecture?
>>
>> - should URI be in Unicode and not in US-ASCII by default to promote
>> internationalization (and accommodating alien languages ;)
>>
>> Nits:
>>
>> - RFC editor recommends putting quotation marks before commas and
> periods
>> ".
>> - RFC editor discourages use of URLs in the text, p.4 (and is some
>> references)
>> - Use of period is not consistent for bulleted lists, e.g. p. 12
>> - Something is wrong with whens on top of p. 13
>> - Comma missing in ref [JDPF05]
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Review of arch-05...
Date: Fri, 5 May 2006 07:31:30 -0700
From: "Fall, Kevin" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "DTN" <[email-masked]>
Cc: "Andrei Gurtov" <[email-masked]>
Sender: [email-masked]

Hi.  I think I'm basically comfortable with the document as-is.  The
nits, I believe, we can change during the "here's your last chance to
make editorial changes" portion from the rfc-editor before the final RFC
number is assigned, and I'm willing to do that.

With respect to the other items (non-nits), here is what I think:

1. congestion control -- still an ongoing bit of work in DTN.  There are
some papers beginning to address it, but we don't have a total solution
yet so I'm ok saying so in the draft

2. the identity and locations are separated (or at least are not overtly
linked in any real way-- the id's are URI's, not URL's.).  The
architecture document is careful to say very little about how you
actually arrange your routing and it treats the id's more like strings
than anything else.

3. non-ascii URIs.. hmm.  Well, I guess I'd say that if we really are
beginning to have widespread success we can do that.  For now, I don't
think anybody is actually working on non-ascii URI's in DTN, and to put
them in there at this point I think might cause people to think we are
really doing it when we aren't.  I don't have any particular objection
to such things, however, so I could imagine a future document describing
other forms and encodings for URIs.

Cheers
- K

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Friday, May 05, 2006 7:19 AM
> To: DTN
> Cc: Andrei Gurtov
> Subject: [dtn-interest] Review of arch-05...
> 
> 
> Hi all, but mainly authors of the arch-05,
> 
> Andrei Gurtov kindly did a review of this document as part
> of the process of getting it to be an RFC. His review is
> below.
> 
> Do the authors want to make any changes as a result of
> this? (Note: The process here doesn't require that we
> satisfy the reviewer, but if is of course better to
> fix/improve things where one can...)
> 
> Stephen.
> 
> Andrei's review:
> 
> Below please find my review of the DTNRG arch draft.
> The draft is of high quality and ready to go if the authors believe
so.
> Though it would be interesting to discuss following issues:
> 
> - details of congestion control in DTNs is missing from the
> architecture. Is it a feature that can be safely added afterwards or
> should it be considered right from the beginning?
> It would be interesting to consider e.g interactions between
expiration
> losses and congestion response at end points.
> http://portal.acm.org/citation.cfm?id=965738
> 
> - does the architecture support mobility and multihoming well. Should
> the identity and locators be separated in the architecture?
> 
> - should URI be in Unicode and not in US-ASCII by default to promote
> internationalization (and accommodating alien languages ;)
> 
> Nits:
> 
> - RFC editor recommends putting quotation marks before commas and
periods
> ".
> - RFC editor discourages use of URLs in the text, p.4 (and is some
> references)
> - Use of period is not consistent for bulleted lists, e.g. p. 12
> - Something is wrong with whens on top of p. 13
> - Comma missing in ref [JDPF05]
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Fri, 05 May 2006 15:19:01 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
CC: Andrei Gurtov <[email-masked]>
Subject: [dtn-interest] Review of arch-05...
Sender: [email-masked]

Hi all, but mainly authors of the arch-05,

Andrei Gurtov kindly did a review of this document as part
of the process of getting it to be an RFC. His review is
below.

Do the authors want to make any changes as a result of
this? (Note: The process here doesn't require that we
satisfy the reviewer, but if is of course better to
fix/improve things where one can...)

Stephen.

Andrei's review:

Below please find my review of the DTNRG arch draft.
The draft is of high quality and ready to go if the authors believe so.
Though it would be interesting to discuss following issues:

- details of congestion control in DTNs is missing from the 
architecture. Is it a feature that can be safely added afterwards or 
should it be considered right from the beginning?
It would be interesting to consider e.g interactions between expiration 
losses and congestion response at end points.
http://portal.acm.org/citation.cfm?id=965738

- does the architecture support mobility and multihoming well. Should 
the identity and locators be separated in the architecture?

- should URI be in Unicode and not in US-ASCII by default to promote 
internationalization (and accommodating alien languages ;)

Nits:

- RFC editor recommends putting quotation marks before commas and periods ".
- RFC editor discourages use of URLs in the text, p.4 (and is some 
references)
- Use of period is not consistent for bulleted lists, e.g. p. 12
- Something is wrong with whens on top of p. 13
- Comma missing in ref [JDPF05]

Content-class: urn:content-classes:message
Date: Mon, 1 May 2006 11:27:44 -0400
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] Agenda for non-custodial multicast discussion at May  DTNRG meeting
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C66D33.CBD79782
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C66D33.CBD79782"

------_=_NextPart_002_01C66D33.CBD79782
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Symington,
Susan F.
	Sent: Tuesday, April 04, 2006 4:03 PM
	To: [email-masked]
	Subject: [dtn-interest] (no subject)
=09
=09
	All,

	=20

	Here is my proposed agenda for the non-custodial multicast
discussion we need to have.

	=20

	Objective: Conclude our discussion with an agreement on how
non-custodial multicast should be specified in DTN.

	=20

	Summary of the four identified additional mechanisms that are
needed to support non-custodial DTN multicast:

	1.	A way to identify the EID of the node that forwarded a
received bundle.=20
	2.	An assurance that the EID used to identify this
previous hop is the same EID that the receiving node uses to identify
the forwarding node (and not some other alias EID of the forwarding
node)=20
	3.	A way to eliminate or sufficiently mitigate potential
implosion at the report-to endpoint from a multicast bundle that
requests status report generation=20
	4.	If support for multicast is optional rather than
mandatory, a way to encapsulate multicast bundles inside of unicast
bundles.

	Summary of the proposals made at the Dallas DTNRG meeting to
address the need for the above mechanisms:

	1.	Define an optional Previous Hop EID extension header
(in a separate, stand-alone specification) that a forwarding node
inserts into a bundle to identify itself to the receiving node.=20
	2.	Require that each node that is capable of supporting
multicast delivery must have a unique, designated singleton EID that is
the only EID for that node that:=20

		a.	Other nodes use to identify that node when
making forwarding decisions, and=20
		b.	That node will ever put in a Previous Hop EID
header that it creates.

	3.	Require that local policy must be capable of overriding
all requests for status reporting so as to mitigate the risk of status
report implosion at report-to endpoints.=20
	4.	Assuming that support for multicast is optional rather
than mandatory, require multicast-capable nodes to implement
bundle-in-bundle encapsulation (defined in a separate specification)=20

	Specifically we want to answer the following questions which
have arisen in previous discussion:=20

	1.      Should support for non-custodial multicast be mandatory
(in the base bundle protocol) or optional?  By making support
mandatory, we mean that every node would be required to be capable of
generating and processing previous-hop EID headers, though not required
to actually use these headers. (Implementation would be mandatory; use
would remain optional)

	2.      How should the problem of potential implosion at the
report-to endpoint of a multicast bundle be mitigated? Some ideas that
were floated include:

	a.       Turn off generation of all status reports if the
destination endpoint is not a singleton endpoint?=20

	b.      Turn off generation of only the "each-hop" status
reports if destination endpoint is not a singleton endpoint (turn off
only Request reporting of bundle reception and Request reporting of
bundle forwarding; leave on Request reporting of bundle delivery,
Request reporting of bundle deletion, and Request acknowledgement by
application ) (For large groups this could still be a problem.)

	c.       Say that at any node implementing the Bundle Protocol,
local policy may override status report request flags and not send
reports for multicast bundles. (Question here is how any given node has
knowledge necessary to know whether to override or not.)

	3.      What exactly should be the wording of the requirement
that each node have some sort of "designated" EID that denotes it and
that it and other nodes use in specific situations.  (A mechanism for
identifying the previous hop endpoint of a bundle seems to be required
for multicast support. Regardless of how it is implemented, for the
previous-hop EID to be meaningful, there must be a requirement that the
endpoint ID that a node uses to identify itself to others in the
previous hop EID header/field is the same endpoint ID that it's
neighbor nodes use to identify it for the purpose of making forwarding
decisions. Right now there is nothing in the specifications that ensure
that every node has or uses a "designated" EID. Is this a more general
requirement that will be needed to support DTN routing in general or is
it multicast-specific?)

	=20

	Lastly, I am attaching three normative drafts that I put
together based on my presentation at the Dallas meeting. Please look
them over and provide me with comments. They are:

	=20

	1.	Previous Hop Extension Header draft=20
	2.	Bundle-in-Bundle Encapsulation draft=20
	3.	Non-Custodial Multicast Extensions draft

	 The multicast extensions draft assumes that multicast remains
optional, so it would have to be modified slightly if we end up
deciding that multicast is mandatory, but the basic ideas would remain
the same.=20

	=20

	Thanks.

	=20

	-Susan

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

------_=_NextPart_002_01C66D33.CBD79782
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2873" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of =
</B>Symington,=20
  Susan F.<BR><B>Sent:</B> Tuesday, April 04, 2006 4:03 PM<BR><B>To:</B> =

  [email-masked]<BR><B>Subject:</B> [dtn-interest] (no=20
  subject)<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
  face=3D"Times New Roman"><FONT size=3D3><SPAN=20
  class=3D893065919-04042006>All,</SPAN></FONT></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
  face=3D"Times New Roman"><FONT size=3D3><SPAN=20
  class=3D893065919-04042006></SPAN></FONT></FONT>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D+0><SPAN=20
  class=3D893065919-04042006></SPAN><FONT face=3D"Times New Roman"><FONT =

  size=3D3><SPAN class=3D893065919-04042006>Here is my proposed =
a</SPAN>genda=20
  for&nbsp;<SPAN class=3D893065919-04042006>the non-custodial =
</SPAN>multicast=20
  discussion&nbsp;<SPAN class=3D893065919-04042006>we need to=20
  have.</SPAN></FONT></FONT></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20
  face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
  size=3D3>Objective: Conclude our discussion with an agreement on how=20
  non-custodial multicast should be specified in DTN.</FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20
  face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
  size=3D3>Summary of the four identified additional mechanisms that are =
needed to=20
  support non-custodial DTN multicast:</FONT></P>
  <OL style=3D"MARGIN-TOP: 0in" type=3D1>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l3 level1 lfo2; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>A way to identify the EID of the =
node that=20
    forwarded a received bundle. </FONT>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l3 level1 lfo2; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>An assurance that the EID used to =
identify=20
    this previous hop is the same EID that the receiving node uses to =
identify=20
    the forwarding node (and not some other alias EID of the forwarding=20
    node)</FONT>=20
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l3 level1 lfo2; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>A way to eliminate or sufficiently =
mitigate=20
    potential implosion at the report-to endpoint from a multicast =
bundle that=20
    requests status report generation</FONT>=20
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l3 level1 lfo2; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>If support for multicast is =
optional rather=20
    than mandatory, a way to encapsulate multicast bundles inside of =
unicast=20
    bundles.</FONT></LI></OL>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
  size=3D3>Summary of the proposals made at the Dallas DTNRG meeting to =
address=20
  the need for the above mechanisms:</FONT></P>
  <OL style=3D"MARGIN-TOP: 0in" type=3D1>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo3; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>Define an optional Previous Hop =
EID extension=20
    header (in a separate, stand-alone specification) that a forwarding =
node=20
    inserts into a bundle to identify itself to the receiving =
node.</FONT>=20
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo3; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>Require that each node that is =
capable of=20
    supporting multicast delivery must have a unique, designated =
singleton EID=20
    that is the only EID for that node that:</FONT>=20
    <OL style=3D"MARGIN-TOP: 0in" type=3Da>
      <LI class=3DMsoNormal=20
      style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo3; tab-stops: =
list 1.0in"><FONT=20
      face=3D"Times New Roman" size=3D3>Other nodes use to identify that =
node when=20
      making forwarding decisions, and</FONT>=20
      <LI class=3DMsoNormal=20
      style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo3; tab-stops: =
list 1.0in"><FONT=20
      face=3D"Times New Roman" size=3D3>That node will ever put in a =
Previous Hop=20
      EID header that it creates.</FONT></LI></OL>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo3; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>Require that local policy must be =
capable of=20
    overriding all requests for status reporting so as to mitigate the =
risk of=20
    status report implosion at report-to endpoints.</FONT>=20
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo3; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>Assuming that support for =
multicast is=20
    optional rather than mandatory, require multicast-capable nodes to =
implement=20
    bundle-in-bundle encapsulation (defined in a separate specification) =

    </FONT></LI></OL>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
  face=3D"Times New Roman"><FONT size=3D3>Specifically we want to answer =
the=20
  following questions<SPAN class=3D893065919-04042006> which have arisen =
in=20
  previous discussion</SPAN>:<o:p>&nbsp;</o:p></FONT></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt 39pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level1 lfo1; tab-stops: list 39.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
  size=3D3>1.</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN><FONT size=3D3>Should support for non-custodial =
multicast be=20
  mandatory (in the base bundle protocol) or optional?<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>By making support mandatory, =
we mean=20
  that every node would be required to be capable of generating and =
processing=20
  previous-hop EID headers, though not required to actually use these =
headers.=20
  (Implementation would be mandatory; use would remain=20
  optional)</FONT></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt 39pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level1 lfo1; tab-stops: list 39.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
  size=3D3>2.</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN><FONT size=3D3>How should the problem of potential =
implosion at=20
  the report-to endpoint of a multicast bundle be mitigated? Some ideas =
that=20
  were floated include:</FONT></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt 75pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level2 lfo1; tab-stops: list 75.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
  size=3D3>a.</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN><FONT size=3D3>Turn off generation of all status reports =
if the=20
  destination endpoint is not a singleton endpoint? </FONT></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt 75pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level2 lfo1; tab-stops: list 75.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
  size=3D3>b.</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN><FONT size=3D3>Turn off generation of only the =
&#8220;each-hop&#8221; status=20
  reports if destination endpoint is not a singleton endpoint (turn off =
only=20
  Request reporting of bundle reception and Request reporting of bundle=20
  forwarding; leave on Request reporting of bundle delivery, Request =
reporting=20
  of bundle deletion, and Request acknowledgement by application ) (For =
large=20
  groups this could still be a problem.)</FONT></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt 75pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level2 lfo1; tab-stops: list 75.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
  size=3D3>c.</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN><FONT size=3D3>Say that at any node implementing the =
Bundle=20
  Protocol, local policy may override status report request flags and =
not send=20
  reports for multicast bundles. (Question here is how any given node =
has=20
  knowledge necessary to know whether to override or =
not.)</FONT></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt 39pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level1 lfo1; tab-stops: list 39.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
  size=3D3>3.</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN><FONT size=3D3>What exactly should be the wording of the =

  requirement that each node have some sort of &#8220;designated&#8221; =
EID that denotes it=20
  and that it and other nodes use in specific situations.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>(A mechanism for identifying =
the=20
  previous hop endpoint of a bundle seems to be required for multicast =
support.=20
  Regardless of how it is implemented, for the previous-hop EID to be=20
  meaningful, there must be a requirement that the endpoint ID that a =
node uses=20
  to identify itself to others in the previous hop EID header/field is =
the same=20
  endpoint ID that it&#8217;s neighbor nodes use to identify it for the =
purpose of=20
  making forwarding decisions. Right now there is nothing in the =
specifications=20
  that ensure that every node has or uses a &#8220;designated&#8221; =
EID. Is this a more=20
  general requirement that will be needed to support DTN routing in =
general or=20
  is it multicast-specific?)</FONT></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20
  face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
  size=3D3>Lastly, I am attaching three normative drafts that I put =
together based=20
  on my presentation at the <st1:City w:st=3D"on"><st1:place=20
  w:st=3D"on">Dallas</st1:place></st1:City> meeting. Please look them =
over and=20
  provide me with comments. They are:</FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20
  face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></P>
  <OL style=3D"MARGIN-TOP: 0in" type=3D1>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l1 level1 lfo4; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>Previous Hop Extension Header =
draft</FONT>=20
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l1 level1 lfo4; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>Bundle-in-Bundle Encapsulation =
draft</FONT>=20
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l1 level1 lfo4; tab-stops: =
list .5in"><FONT=20
    face=3D"Times New Roman" size=3D3>Non-Custodial Multicast Extensions =

    draft</FONT></LI></OL>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D3><FONT=20
  face=3D"Times New Roman"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;</SPAN>The=20
  multicast extensions draft assumes that multicast remains optional, so =
it=20
  would have to be modified slightly if we end up deciding that =
multicast is=20
  mandatory, but the basic ideas would remain the same. =
</FONT></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20
  face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
  size=3D3>Thanks.</FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20
  face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
  size=3D3>-Susan</FONT></P></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV align=3Dleft><FONT face=3DArial=20
  =
size=3D2>****************************************************************=
*</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
  <DIV align=3Dleft><FONT face=3DArial=20
  =
size=3D2>****************************************************************=
**</FONT></DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_002_01C66D33.CBD79782--

------_=_NextPart_001_01C66D33.CBD79782
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-encapsulation-04-04-2006.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-encapsulation-04-04-2006.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-encapsulation-04-04-2006.txt"

ICAgICAgICAgICAgICAgIFtQYWdlIDldCgwK

------_=_NextPart_001_01C66D33.CBD79782
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-previous-hop-extension-header-04-04-2006.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-previous-hop-extension-header-04-04-2006.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-previous-hop-extension-header-04-04-2006.txt"

------_=_NextPart_001_01C66D33.CBD79782
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-multicast-noncustodial-protocol-extensions-04-04-2006.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-multicast-noncustodial-protocol-extensions-04-04-2006.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-multicast-noncustodial-protocol-extensions-04-04-2006.txt"

------_=_NextPart_001_01C66D33.CBD79782--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Berkeley DTNRG meeting May 16/17
Date: Mon, 1 May 2006 11:26:32 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Fall, Kevin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Kevin Fall wrote:
>
>DTNRG Meeting
>Intel Berkeley Lab
>May 16-17, 2006
> [...]
>
>Topics for discussion:
>
>Multicast
>
>	please see Susan Symington's note to dtn-interest from
2/28/2006
>	as well as her ID for background
>	
>http://www.ietf.org/internet-drafts/draft-symington-bundle-mult
>icast-non
>custodial-00.txt
>

Actually,  I don't recommend you read the above-referenced draft at
this point. Instead, the best way to bring yourself up to speed on DTN
multicast would be to read the three normative drafts that we put
together based on comments that were received on the above-referenced
draft. These three drafts were mailed to dtn-interest along with an
email outlining the multicast topics for discission on 4/4/06, with the
unfortunate subject line of "(no subject)" (note, this is a different
email than the 2/28/06 email referenced above). 

I am going to resend that email and the three drafts in a separate
email.
 
-susan