Subject: [dtn-interest] CHANTS 2008 Call for Demos Reminder
From: Katia Obraczka <[email-masked]>
To: [email-masked], [email-masked]
Date: Sun, 25 May 2008 22:04:51 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

The demo submission deadline for CHANTS 08 is fast approaching. See
the Call for Demos below.

					Katia Obraczka
					UC Santa Cruz
					CHANTS'08 Demo Chair

==============
Call for Demos
Third Workshop on Challenged Networks (CHANTS 2008)
Co-located with Mobicom 2008, 15 September 2008, San Francisco, CA, USA

Workshop URI:			http://wavedesk.usc.edu/chants/

Important Dates: 
Demo submission deadline:              5 June 2008
Demo acceptance notification:         16 June 2008
Camera-ready due:     	           29 June 2008
Workshop date:                     15 September 2008

Challenged networks are characterized by a heterogeneous mix of nodes
and widely varying network conditions.  Nodes in today's challenged
networks often include mobile nodes, space-based nodes,
sensor/actuator nodes and other devices.  Performance of the network
paths interconnecting such nodes can be highly varying in terms of
bandwidth, latency, disruption characteristics and security
requirements.  Conventional Internet access in performance-limited
environments such as developing countries can also be regarded as
challenged networks as can be ad-hoc communication between personal
devices.

The Internet protocol architecture suffers some problems when used in
a challenged network setting.  For example, when disconnection and
reconnection is common or link performance is highly variable or
extreme, one or more of the traditional Internet protocols do not work
well. In this workshop following CHANTS 2007, CHANTS 2006 and WDTN
2005, we wish to explore ongoing efforts in dealing with physical
networks that operate significantly differently from wired, connected
networks and the protocol architectures and algorithms used to deal
with such situations.  Techniques for making applications tolerant to
disruptions and/or high delays are also in scope.

CHANTS 2008 Demonstration Program offers an excellent way to showcase
to attendees from academia and industry tangible results from research
and development in the exciting area of challenged networks. Demos
have the ability to communicate ideas and concepts in a very powerful
way. We invite you to contribute your vision and experience with
challenged networks to CHANTS 2008 Demonstration Program. Demo
proposals shall present recent practical results from the area of
challenged networks.  In exceptional cases, where live demos are
simply not practical to present, poster or video presentations of
practical results are acceptable, too. Accepted demonstration
abstracts will be published in the Conference proceedings.

Topics:

	Characterization of performance-challenged networks e.g. 
                  measurements, modelling.
	Networking systems operating over unusual/challenged networks.
	Protocol design and evaluation of operations over challenged 
                  networks.
	System architecture and design for challenged networks.
	Applications in challenged networks.
	Robust network application design and implementation techniques.
	Delay tolerant and disruption tolerant networks (DTN).
	Configuration and management of challenged networks.

Format and submission instructions:

Demo proposal abstracts (to be published as part of the proceedings)
shall not be longer than 3 pages plus 1 page description of the
precise setup and requirements.  Submitted abstracts should be
formatted in two columns, with characters no smaller than 10 point
fonts, and must fit properly on US "Letter"-sized paper (8.5x11
inches). Margins must be of 1 inch on all edges (top, bottom, left,
and right) of each page. Demo proposals should be sent as a pdf e-mail
attachment to [email-masked].

_______________________________________________
Tccc mailing list
[email-masked]
https://lists.cs.columbia.edu/cucslists/listinfo/tccc

----- End forwarded message -----

Content-class: urn:content-classes:message
Date: Fri, 23 May 2008 07:58:38 -0500
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>, "Kevin Fall" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] paper describing DTN bundling from space

Also,  You get input from a different audience as you should have a
larger draw from Europe and (perhaps even Africa).  

Will

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Lloyd Wood
> Sent: Thursday, May 22, 2008 9:01 AM
> To: Kevin Fall
> Cc: [email-masked]
> Subject: Re: [dtn-interest] paper describing DTN bundling from space
> 
> It's a shame to skip Dublin, as the Philadelphia session was 
> so packed and rushed.
> 
> L.
> 
> DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> On 21 May 2008, at 23:30, Kevin Fall wrote:
> 
> > Nominally we meet every other time, so Dublin would be an 
> "off" one, 
> > meaning the following meeting (Minneapolis) will be the 
> next "on" one.
> >
> > - K
> >
> > On May 21, 2008, at May 213:26 PMPDT, Stephen Farrell wrote:
> >
> >>
> >>
> >> Lloyd Wood wrote:
> >>> and will there be a DTNRG meet in Dublin? I don't think 
> I've seen a 
> >>> confirmation one way or the other.
> >>
> >> I've not seen a groundswell of desire so as of now, I think we'll 
> >> skip this one and maybe meet next time.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Lloyd Wood <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Thu, 22 May 2008 14:00:53 +0100
Cc: [email-masked]
Subject: Re: [dtn-interest] paper describing DTN bundling from space

It's a shame to skip Dublin, as the Philadelphia session was so packed  
and rushed.

L.

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

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

On 21 May 2008, at 23:30, Kevin Fall wrote:

> Nominally we meet every other time, so Dublin would be an "off" one,  
> meaning the following meeting (Minneapolis) will be the next "on" one.
>
> - K
>
> On May 21, 2008, at May 213:26 PMPDT, Stephen Farrell wrote:
>
>>
>>
>> Lloyd Wood wrote:
>>> and will there be a DTNRG meet in Dublin? I don't think I've seen  
>>> a confirmation one way or the other.
>>
>> I've not seen a groundswell of desire so as of now, I think we'll
>> skip this one and maybe meet next time.

From: Kevin Fall <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 21 May 2008 15:30:18 -0700
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] paper describing DTN bundling from space

Nominally we meet every other time, so Dublin would be an "off" one,  
meaning the following meeting (Minneapolis) will be the next "on" one.

- K

On May 21, 2008, at May 213:26 PMPDT, Stephen Farrell wrote:

>
>
> Lloyd Wood wrote:
>> and will there be a DTNRG meet in Dublin? I don't think I've seen a  
>> confirmation one way or the other.
>
> I've not seen a groundswell of desire so as of now, I think we'll
> skip this one and maybe meet next time.
>
> S.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Wed, 21 May 2008 23:26:32 +0100
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] paper describing DTN bundling from space

Lloyd Wood wrote:
> and will there be a DTNRG meet in Dublin? I don't think I've seen a confirmation one way or the other.

I've not seen a groundswell of desire so as of now, I think we'll
skip this one and maybe meet next time.

S.

Date: Wed, 21 May 2008 20:07:53 +0100
To: [email-masked]
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] paper describing DTN bundling from space

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

We've written up a paper describing our experiments with using DTN bundles from a satellite in orbit - the first use of DTN bundles from space.

(thanks to Vint for the T-shirts.)

L.

and will there be a DTNRG meet in Dublin? I don't think I've seen a confirmation one way or the other.

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

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

From: Rajesh Krishnan <[email-masked]>
To: [email-masked]
Date: Sun, 11 May 2008 11:48:11 -0400
Subject: [dtn-interest] [Fwd: Re: [e2e] end of interest -- BP metadata / binary vs text]

Last of three posts that I am forwarding from e2e that I think are
on-topic for dtn-interest.

Best Regards,
Rajesh

-------- Forwarded Message --------
> From: Rajesh Krishnan <[email-masked]>
> To: David P. Reed <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [e2e] end of interest -- BP metadata / binary vs text
> Date: Sun, 11 May 2008 11:30:11 -0400
> 
> David,
> 
> My objective was to provoke discussion on the topic of whether it makes
> sense to think of DTN as a session layer, as an overlay above TCP, etc.
> from the e2e perspective.  If you feel this topic is unsuitable for
> discussion here, I will gladly stop posting on this topic here of
> course.
> 
> > I am afraid that those who treat the RFCs as scripture from high priests 
> > mistake dogma for thoughtfulness.
> 
> I am definitely not treating RFCs as scripture.  I am not satisfied with
> the explanation that DTN/BP belongs to the "session layer" as the best
> or only model.  I find this limiting, since DTN issues span all the way
> from applications to the physical "layer".
> 
> > The essential valid measure of DTN ideas is that they work, and will 
> > continue to work well, *to organize the solution* to an interesting 
> > class of real-world problems.   It is irrelevant whether they provide 
> > the basis for destroying some "traditional paradigm" and creating a new 
> > religion.
> 
> Agreed.  If anyone reads my post as being about destroying old religion
> and creating a new one, that is missing the point.  It is about getting
> out of old shackles though; why keep doing the same thing (like the way
> we fit seem to try to fit DTN into the old mold) and expect a different
> result?   If we say DTN is in the session layer, we will engineer a
> useful DTN session layer alright, but will a DTN session layer solve any
> fundamentally new problems?  Does that limit new architectures that
> could be explored?
> 
> > What made the Internet architecture useful was its attention to 
> > "interoperation" and to facilitating support of "unanticipated" 
> > applications and implementation technologies.  It framed those things 
> > well, making progress possible.  DTN ideas frame a new set of issues 
> > well - communcations that occur between entities that occupy 
> > discontiguous regions of space-time influence.   Such communications 
> > have always existed (books communicate across time in personal and 
> > public libraries, postal letters transcend spatial barriers in 
> > self-contained form) - DTN's merely ratify their importance by focusing 
> > framing on those issues.
> 
> Agreed.  In a DTN, among other things, we want to maximize the value of
> information exchanged within a transitory encounter, and this can not be
> framed entirely as a session-layer issue.  Relegating DTN to the session
> layer will completely isolate it from a radio-aware CLA (or whatever
> name we want to call it) among other things, which relates to a point
> you made earlier.
> 
> Hope that clarifies my original post somewhat.
> 
> Best Regards,
> Rajesh
> 
> > Rajesh Krishnan wrote:
> > >
> > > Granted this matches the viewpoint presented in RFC 5050 of BP's
> > > (non-threatening ;) relationship to TCP/IP.
> > >
> > > By including forwarding and dynamic routing (L3?), retransmissions
> > (L4?
> > > and L2?), and persistent storage and application metadata tagging
> > (L7?)
> > > concerns within the same protocol, BP does not fit harmoniously at
> > L5 of
> > > the TCP/IP Internet, IMHO.  This challenge to traditional layering
> > is
> > > precisely what I find most fascinating about DTN.
> > >
> > > With the CLA/BP split, there is still layering in DTN; just that the
> > > layering is not congruent to conventional TCP/IP layering.
> > Effectively,
> > > DTN/BP seems to relate to TCP/IP more or less the same way IP looks
> > at
> > > other network technologies.  At least that is my interpretation of
> > > DTN/BP as an overlay abstraction (TCP/IP is relevant only as
> > expedient
> > > means for early deployment.  ;)
> > >
> > > I am speaking only for myself here (not past or present employers or
> > > funding agencies or IRTF WGs), and this thread ought to migrate to
> > > dtn-interest perhaps.
> > >
> > > Best Regards,
> > > Rajesh

From: Rajesh Krishnan <[email-masked]>
To: [email-masked]
Date: Sun, 11 May 2008 11:40:34 -0400
Subject: [dtn-interest] [Fwd: Re: [e2e] end of interest -- BP metadata / binary vs text]

>From e2e

-------- Forwarded Message --------
> From: David P. Reed <[email-masked]>
> To: Rajesh Krishnan <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: [e2e] end of interest -- BP metadata / binary vs text
> Date: Sun, 11 May 2008 10:36:34 -0400
> 
> "Traditional layering" my a**.  When the present Internet architecture 
> was constructed in the 1970's there was no OSI model at all.  It would 
> be revisionist (alas too common) to imagine that the *goal* of 
> communications architecture is to fit into a frame (OSI) that was 
> conceived ex post as merely an explanatory tool for the decisions about 
> modularity that were made on far more serious grounds than a mere 
> picture of a stack.
> 
> The "end to end argument" was a pattern of argumentation used to 
> organize architectural thinking.
> 
> I am afraid that those who treat the RFCs as scripture from high priests 
> mistake dogma for thoughtfulness.
> 
> RFCs started out as a frame for discussion.  For making convincing 
> arguments.  The act of granting an RFC a number does not (anymore than 
> acceptance at a peer reviewed journal does not) create a "fact" or a 
> "truth".
> 
> And now many on this list (which used to be above all that) behave like 
> Talmudic scholars or law professors - somehow thinking that by studying 
> merely the grammar and symbols we can ascertain what is right, what is 
> good, or what is fit to purpose.
> 
> The essential valid measure of DTN ideas is that they work, and will 
> continue to work well, *to organize the solution* to an interesting 
> class of real-world problems.   It is irrelevant whether they provide 
> the basis for destroying some "traditional paradigm" and creating a new 
> religion.
> 
> What made the Internet architecture useful was its attention to 
> "interoperation" and to facilitating support of "unanticipated" 
> applications and implementation technologies.  It framed those things 
> well, making progress possible.  DTN ideas frame a new set of issues 
> well - communcations that occur between entities that occupy 
> discontiguous regions of space-time influence.   Such communications 
> have always existed (books communicate across time in personal and 
> public libraries, postal letters transcend spatial barriers in 
> self-contained form) - DTN's merely ratify their importance by focusing 
> framing on those issues.
> 
> 
> 
> Rajesh Krishnan wrote:
> >
> > Granted this matches the viewpoint presented in RFC 5050 of BP's
> > (non-threatening ;) relationship to TCP/IP.
> >
> > By including forwarding and dynamic routing (L3?), retransmissions (L4?
> > and L2?), and persistent storage and application metadata tagging (L7?)
> > concerns within the same protocol, BP does not fit harmoniously at L5 of
> > the TCP/IP Internet, IMHO.  This challenge to traditional layering is
> > precisely what I find most fascinating about DTN.
> >
> > With the CLA/BP split, there is still layering in DTN; just that the
> > layering is not congruent to conventional TCP/IP layering.  Effectively,
> > DTN/BP seems to relate to TCP/IP more or less the same way IP looks at
> > other network technologies.  At least that is my interpretation of
> > DTN/BP as an overlay abstraction (TCP/IP is relevant only as expedient
> > means for early deployment.  ;)
> >
> > I am speaking only for myself here (not past or present employers or
> > funding agencies or IRTF WGs), and this thread ought to migrate to
> > dtn-interest perhaps.
> >
> > Best Regards,
> > Rajesh
> >
> >
> >
> >
> >   

From: Rajesh Krishnan <[email-masked]>
To: [email-masked]
Date: Sun, 11 May 2008 11:39:24 -0400
Subject: [dtn-interest] [Fwd: RE: [e2e] end of interest -- BP metadata / binary vs text]

Was on e2e

-------- Forwarded Message --------
> From: [email-masked]
> To: [email-masked], [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: RE: [e2e] end of interest -- BP metadata / binary vs text
> Date: Sat, 10 May 2008 19:38:37 +0100
> 
> 
> 
> BEEP gives us MIME, but is inherently rigidly transactional
> (RFC3080 section 2.1.1), which puts it as a disadvantage
> for long-delay links. HTTP PUTs can be entirely one-way...
> never mind BEEP's profile uri's. (I do find the HTTP specs far
> easier to read and follow.)
> 
> HTTP, BEEP and the Bundle Protocol aren't network protocols...
> really session layers (well, the BP's always compared to email,
> and an email message can be thought of as a session?). Doing
> sessions as text helps for debugging and modifications.
> 
> L.
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> -----Original Message-----
> From: Jon Crowcroft [mailto:[email-masked]]
> Sent: Sat 2008-05-10 17:19
> To: Rajesh Krishnan
> Cc: Wood L Dr (Electronic Eng); [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [e2e] end of interest -- BP metadata / binary vs text
> 
> yep
> 
> two alternates to the BP stuff suggest themselves...
> 
> 1. Blocks/BEEP:
> http://www.ietf.org/rfc/rfc3080.txt
> if you are http mindfuk
> and
> 2. some of the data naming/framing ideas in Reliable Multicast
> http://portal.acm.org/citation.cfm?id=290808
> if you are more rad
> 
> In missive <[email-masked]>, Rajesh
> Krishnan typed:
> 
>  >>Lloyd,
>  >>
>  >>Yes, we discussed this on dtn-interest.   What you say regarding
> text
>  >>being successful has been true of many application protocols, while
>  >>network/lower layer protocols favor a binary form. I do not have a
>  >>preference for either -- text is convenient until there is sizeable
>  >>metadata that is intrinsically binary (index shot thumbnail of a
> movie
>  >>scene).
>  >>
>  >>I view BP or its successor as having the potential for being a
>  >>storage-aware network layer protocol rather than remain at the
>  >>session/application layer of a TCP/IP network.   Rose-colored
>  >>glasses?  :)
>  >>
>  >>Best Regards,
>  >>Rajesh
>  >>
>  >>
>  >>
>  >>> Rajesh,
>  >>>
>  >>> The DTN Bundle Protocol uses an obscure binary format for its
>  >>> metadata blocks. If you want flexible user-definable metadata,
>  >>> it really has to be text. For this reason, we proposed using HTTP
>  >>> as a transport-layer-independent session layer for DTN networks:
>  >>>
>  >>> http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-01
>  >>> http://www.ietf.org/proceedings/08mar/slides/DTNRG-6.pdf
>  >>>
>  >>> Getting content identification via MIME (which the Bundle
> Protocol
>  >>> doesn't do) is a bonus. Gopher is an example of a binary format
>  >>> that didn't succeed against HTTP.
>  >>>
>  >>> L.
>  >>>
>  >>> just another of those PhD-toting technicians.
>  >>>
>  >>> DTN work: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
>  >>>
>  >>>
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>  >>>
>  >>> Rajesh Krishnan wrote on Sat 2008-05-10 1:02:
>  >>>
>  >>> > Networks seem to need a critical mass of adoption, and usually
> an
>  >>> > evolutionarily smart vector to succeed.  The DTN Bundle
> Protocol (or
>  >>> its
>  >>> > successor, with metadata extension block semantics that will
>  >>> hopefully
>  >>> > remain flexible and user-definable) might just offer an
> opportunity
>  >>> for
>  >>> > acquiring a new critical mass, but only if it finds the smart
> vector
>  >>> > (that does what Mosaic did for HTTP/HTML, and perhaps BSD for
>  >>> TCP/IP).
>  >>>
>  >>>
>  >>
> 
>  cheers
> 
>    jon
> 
> 
> 
> 

Date: Wed, 07 May 2008 15:05:20 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] IANA registry for LTP (and the BP?)

Peter Lovell wrote:
> Hi Stephen,
> 
> I think that having a registry is a good idea although I think that the
> ciphersuite details are not quite firm enough yet. 

I guess you mean for the BSP. We should probably add some IANA stuff
in the next rev of the BSP spec I guess, just to get the ball rolling.
Will you add that to your list? You can use whatever I draft for the
LTP stuff as a template.

The LTP ciphersuites are cooked sufficiently to go ahead with a
registry now.

> "Good plan - go for it"

Thanks,
S.

> 
> Cheers.....Peter
> 
> 
> 
> On Wed, May 7, 2008, Stephen Farrell <[email-masked]> wrote:
> 
>> Ok, so that got a stunning response - guess registries aren't
>> what get people here excited, which is fair enough:-)
>>
>> But the IANA folks've now asked as well, so we need some
>> kind of answer.
>>
>> Assuming no further input, I'm going to propose that we
>> ask IANA to set up LTP registries for the extension types and
>> ciphersuites, with the update rule for both being "specification
>> required" where the specification can be an RFC (of any type)
>> or any other SDO's publicly available specification (wording
>> for that might be tricky so we might get reduced to needing
>> an RFC).
>>
>> I'll ask them to do that tomorrow, so yell now if it's a problem.
>> We can address the BP registry issues later.
>>
>> Stephen.
>>
>> Stephen Farrell wrote:
>>> The comment we got about LTP extensions was:
>>>
>>>  > An IANA registry for LTP extension values seems appropriate. Since
>>>  > [LTPSPEC] does not establish one, it should probably happen here to
>>>  > assign the two values used here and have a place to register more.
>>>  >
>>>  > Since the extension space is small, I recommend expert review as the
>>>  > policy for new assignments.
>>>
>>> I think (anyone know for sure?) that the relevant guidelines here
>>> are BCP 26. [1]
>>>
>>> So the questions are whether or not to do this for LTP extensions
>>> (and maybe ciphersuites) and secondly for extensible bits of the
>>> BP (block types, ciphersuites, anything else?).
>>>
>>> And if we do want any IANA registries, then what rules should
>>> we adopt for updates?
>>>
>>> I guess there is the possibility that CCSDS's DTN group might
>>> want to extend LTP and/or the BP, so maybe it is a good idea
>>> for us to think about this now. If anyone knows of other groups
>>> that might want to create their own extensions or blocks that'd
>>> be useful input here too.
>>>
>>> As I said in the other mail, my plan for LTP would be to create
>>> a new draft-irtf-dtnrg-ltp-iana to document whatever it is we
>>> think is the right thing to do. (If anyone wants to take on
>>> doing that, let Kevin and I know.)
>>>
>>> Thoughts?
>>>
>>> Stephen.
>>>
>>> [1] http://tools.ietf.org/html/bcp26
>>>
>>>
>>> _______________________________________________
>>> 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: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Date: Wed, 7 May 2008 23:59:07 +1000
Cc: DTN <[email-masked]>
Subject: [dtn-interest] Re(2):  IANA registry for LTP (and the BP?)

Hi Stephen,

I think that having a registry is a good idea although I think that the
ciphersuite details are not quite firm enough yet. 

"Good plan - go for it"

Cheers.....Peter

On Wed, May 7, 2008, Stephen Farrell <[email-masked]> wrote:

>
>Ok, so that got a stunning response - guess registries aren't
>what get people here excited, which is fair enough:-)
>
>But the IANA folks've now asked as well, so we need some
>kind of answer.
>
>Assuming no further input, I'm going to propose that we
>ask IANA to set up LTP registries for the extension types and
>ciphersuites, with the update rule for both being "specification
>required" where the specification can be an RFC (of any type)
>or any other SDO's publicly available specification (wording
>for that might be tricky so we might get reduced to needing
>an RFC).
>
>I'll ask them to do that tomorrow, so yell now if it's a problem.
>We can address the BP registry issues later.
>
>Stephen.
>
>Stephen Farrell wrote:
>> The comment we got about LTP extensions was:
>> 
>>  > An IANA registry for LTP extension values seems appropriate. Since
>>  > [LTPSPEC] does not establish one, it should probably happen here to
>>  > assign the two values used here and have a place to register more.
>>  >
>>  > Since the extension space is small, I recommend expert review as the
>>  > policy for new assignments.
>> 
>> I think (anyone know for sure?) that the relevant guidelines here
>> are BCP 26. [1]
>> 
>> So the questions are whether or not to do this for LTP extensions
>> (and maybe ciphersuites) and secondly for extensible bits of the
>> BP (block types, ciphersuites, anything else?).
>> 
>> And if we do want any IANA registries, then what rules should
>> we adopt for updates?
>> 
>> I guess there is the possibility that CCSDS's DTN group might
>> want to extend LTP and/or the BP, so maybe it is a good idea
>> for us to think about this now. If anyone knows of other groups
>> that might want to create their own extensions or blocks that'd
>> be useful input here too.
>> 
>> As I said in the other mail, my plan for LTP would be to create
>> a new draft-irtf-dtnrg-ltp-iana to document whatever it is we
>> think is the right thing to do. (If anyone wants to take on
>> doing that, let Kevin and I know.)
>> 
>> Thoughts?
>> 
>> Stephen.
>> 
>> [1] http://tools.ietf.org/html/bcp26
>> 
>> 
>> _______________________________________________
>> 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, 07 May 2008 08:23:16 +0100
From: Stephen Farrell <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] IANA registry for LTP (and the BP?)

Ok, so that got a stunning response - guess registries aren't
what get people here excited, which is fair enough:-)

But the IANA folks've now asked as well, so we need some
kind of answer.

Assuming no further input, I'm going to propose that we
ask IANA to set up LTP registries for the extension types and
ciphersuites, with the update rule for both being "specification
required" where the specification can be an RFC (of any type)
or any other SDO's publicly available specification (wording
for that might be tricky so we might get reduced to needing
an RFC).

I'll ask them to do that tomorrow, so yell now if it's a problem.
We can address the BP registry issues later.

Stephen.

Stephen Farrell wrote:
> The comment we got about LTP extensions was:
> 
>  > An IANA registry for LTP extension values seems appropriate. Since
>  > [LTPSPEC] does not establish one, it should probably happen here to
>  > assign the two values used here and have a place to register more.
>  >
>  > Since the extension space is small, I recommend expert review as the
>  > policy for new assignments.
> 
> I think (anyone know for sure?) that the relevant guidelines here
> are BCP 26. [1]
> 
> So the questions are whether or not to do this for LTP extensions
> (and maybe ciphersuites) and secondly for extensible bits of the
> BP (block types, ciphersuites, anything else?).
> 
> And if we do want any IANA registries, then what rules should
> we adopt for updates?
> 
> I guess there is the possibility that CCSDS's DTN group might
> want to extend LTP and/or the BP, so maybe it is a good idea
> for us to think about this now. If anyone knows of other groups
> that might want to create their own extensions or blocks that'd
> be useful input here too.
> 
> As I said in the other mail, my plan for LTP would be to create
> a new draft-irtf-dtnrg-ltp-iana to document whatever it is we
> think is the right thing to do. (If anyone wants to take on
> doing that, let Kevin and I know.)
> 
> Thoughts?
> 
> Stephen.
> 
> [1] http://tools.ietf.org/html/bcp26
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 06 May 2008 23:35:07 +0300
From: Joerg Ott <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] The ONE v1.1.0 beta available

Hi,

we just put up a new release (1.1) of the ONE simulator.
A summary of new features is included below.

The small bullet "- DTN2 connectivity (requires JDK 6 or higher)"
indicates that this release of the ONE now supports connecting
to dtnds of the DTN reference implementation via the external
convergence layer interface and allows routing real DTN2 messages
via the virtual environment modeled in the ONE.

Special thanks to Ari Keränen for the new release and Teemu Kärkkäinen
specifically for (but not limited to) the convergence layer interface.

As a heads-up: We are planning on releasing our "Working Day
Movement Model" integrated into the ONE with version 1.2;
should be out in a couple (surely > 3) of weeks.

Joerg

-------- Alkuperäinen viesti / Orig.Msg. --------
Aihe: [theONE] The ONE v1.1.0 beta available
Päiväys: Tue, 06 May 2008 23:08:49 +0300
Lähettäjä: Ari Keränen <[email-masked]>
Vastaanottaja: [email-masked]

Hi all,

A new version of the ONE (1.1.0) is now available for download at the
homepage: http://www.netlab.tkk.fi/tutkimus/dtn/theone/

Note that this release is a beta version since it is a combination of
multiple development branches and has not been tested and used as much
as the previous releases. If you find any bugs in it, please let us know
so we can fix them. There are some changes, e.g., in the way how
messages whose transfer is finished at the same time step when the
connection breaks are handled, so the simulation results will not be
identical to those generated by previous versions.

However, this release contains some really nice new features. Especially
I believe you will find the new (additional) way to create messages
using a message event generator class more convenient than just using an
external events file for it. The old event files still work just fine,
but you have to configure them a bit differently (see README for
details). And you can even have multiple event generators working at the
same time! Another new feature worth mentioning is the DTN2 reference
implementation connectivity which makes it possible to pass bundles
between the ONE and the reference implementation in real time.

Here's what has changed since the last release (1.0.1):

- External Events Interface which allows event generator classes that
    can generate external events (such as creating new messages or
    setting up and tearing down connections). See EventQueueHandler
    class for details.
      - due to the EEI, some API changes (in e.g.,
        createNewMessage method)
      - external events file feature is now part of the new interface
      - MessageEventGenerator class for generating uniformly
        distributed message creation patterns
      - new event: ConnectionEvent (supported by StandardEventsReader)
- Configurable message queue modes (random and FIFO)
- Option to automatically delete messages that are already delivered
    to the final recipient
- Small change in the ordering of checks whether transfer has
    already succeeded when the connection has gone down
- Connection class has now getTransferDoneTime method
- Settings class can validate range settings (assertValidRange)
- Classes that need to reset static fields between batch runs can
    register to the "resetting service" at DTNSim class
    (registerForReset)
- Experimental "update scheduling" functionality that can be used to
    dynamically insert "update points" between time steps for higher
    precision simulations
- DTN2 connectivity (requires JDK 6 or higher)
- Generic property adding feature for Message class (addProperty,
    getProperty and updateProperty)
     - SprayAndWait router uses this now for the copy count
- New tests

Cheers,
Ari
_______________________________________________
theONE mailing list
[email-masked]
https://www.netlab.tkk.fi/mailman/listinfo/theone

Date: Tue, 6 May 2008 13:06:09 -0700
From: Katia Obraczka <[email-masked]>
To: [email-masked], [email-masked]
Subject: [dtn-interest] CHANTS 2008 Call for Demos

Apologies for the multiple postings.

					Katia Obraczka
					UC Santa Cruz
					CHANTS'08 Demo Chair

==============
Call for Demos
Third Workshop on Challenged Networks (CHANTS 2008)
Co-located with Mobicom 2008, 15 September 2008, San Francisco, CA, USA

Workshop URI:			http://wavedesk.usc.edu/chants/

Important Dates: 
Demo submission deadline:              5 June 2008
Demo acceptance notification:         16 June 2008
Camera-ready due:     	           29 June 2008
Workshop date:                     15 September 2008

Challenged networks are characterized by a heterogeneous mix of nodes
and widely varying network conditions.  Nodes in today's challenged
networks often include mobile nodes, space-based nodes,
sensor/actuator nodes and other devices.  Performance of the network
paths interconnecting such nodes can be highly varying in terms of
bandwidth, latency, disruption characteristics and security
requirements.  Conventional Internet access in performance-limited
environments such as developing countries can also be regarded as
challenged networks as can be ad-hoc communication between personal
devices.

The Internet protocol architecture suffers some problems when used in
a challenged network setting.  For example, when disconnection and
reconnection is common or link performance is highly variable or
extreme, one or more of the traditional Internet protocols do not work
well. In this workshop following CHANTS 2007, CHANTS 2006 and WDTN
2005, we wish to explore ongoing efforts in dealing with physical
networks that operate significantly differently from wired, connected
networks and the protocol architectures and algorithms used to deal
with such situations.  Techniques for making applications tolerant to
disruptions and/or high delays are also in scope.

CHANTS 2008 Demonstration Program offers an excellent way to showcase
to attendees from academia and industry tangible results from research
and development in the exciting area of challenged networks. Demos
have the ability to communicate ideas and concepts in a very powerful
way. We invite you to contribute your vision and experience with
challenged networks to CHANTS 2008 Demonstration Program. Demo
proposals shall present recent practical results from the area of
challenged networks.  In exceptional cases, where live demos are
simply not practical to present, poster or video presentations of
practical results are acceptable, too. Accepted demonstration
abstracts will be published in the Conference proceedings.

Topics:

	Characterization of performance-challenged networks e.g. 
                  measurements, modelling.
	Networking systems operating over unusual/challenged networks.
	Protocol design and evaluation of operations over challenged 
                  networks.
	System architecture and design for challenged networks.
	Applications in challenged networks.
	Robust network application design and implementation techniques.
	Delay tolerant and disruption tolerant networks (DTN).
	Configuration and management of challenged networks.

Format and submission instructions:

Demo proposal abstracts (to be published as part of the proceedings)
shall not be longer than 3 pages plus 1 page description of the
precise setup and requirements.  Submitted abstracts should be
formatted in two columns, with characters no smaller than 10 point
fonts, and must fit properly on US "Letter"-sized paper (8.5x11
inches). Margins must be of 1 inch on all edges (top, bottom, left,
and right) of each page. Demo proposals should be sent as a pdf e-mail
attachment to [email-masked].

Date: Sun, 4 May 2008 10:18:52 -0700
From: Katia Obraczka <[email-masked]>
To: Katia Obraczka <[email-masked]>
Subject: [dtn-interest] CHANTS 2008 Call for Demos

--BZaMRJmqxGScZ8Mx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

The Third Workshop on Challenged Networks (CHANTS 2008) co-located
with Mobicom 2008 will include a Demo Session which will provide an
excellent way to showcase to attendees from academia and industry
tangible results from research and development in the exciting area
+of
challenged networks.
  
The Call fo Demos is attached and important dates are as follows:
  
Demo submission deadline:              5 June 2008
Demo acceptance notification:         16 June 2008
Camera-ready due:                  29 June 2008
Workshop date:                     15 September 2008

We look forward to receiving your submission.

                                        Katia Obraczka
                                        UC Santa Cruz
                                        CHANTS08 Demo Chair

--BZaMRJmqxGScZ8Mx
Content-Type: application/pdf
Content-Disposition: attachment; filename="chants-2008-cfd.pdf"
Content-Transfer-Encoding: base64

--BZaMRJmqxGScZ8Mx--

Date: Thu, 01 May 2008 16:21:26 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] IANA registry for LTP (and the BP?)

The comment we got about LTP extensions was:

 > An IANA registry for LTP extension values seems appropriate. Since
 > [LTPSPEC] does not establish one, it should probably happen here to
 > assign the two values used here and have a place to register more.
 >
 > Since the extension space is small, I recommend expert review as the
 > policy for new assignments.

I think (anyone know for sure?) that the relevant guidelines here
are BCP 26. [1]

So the questions are whether or not to do this for LTP extensions
(and maybe ciphersuites) and secondly for extensible bits of the
BP (block types, ciphersuites, anything else?).

And if we do want any IANA registries, then what rules should
we adopt for updates?

I guess there is the possibility that CCSDS's DTN group might
want to extend LTP and/or the BP, so maybe it is a good idea
for us to think about this now. If anyone knows of other groups
that might want to create their own extensions or blocks that'd
be useful input here too.

As I said in the other mail, my plan for LTP would be to create
a new draft-irtf-dtnrg-ltp-iana to document whatever it is we
think is the right thing to do. (If anyone wants to take on
doing that, let Kevin and I know.)

Thoughts?

Stephen.

[1] http://tools.ietf.org/html/bcp26

Date: Thu, 1 May 2008 16:17:12 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] LTP comments from IESG member

Hi,

We got some comments on the LTP specs from an IESG member, almost
all are nice editorial changes, but two are worth a mention here.

The 1st, which should be fine, was a suggestion to rename the
ciphersuites in the security extensions document, i.e. from
OriginAuth to HMAC-SHA1-80 and Signature to RSA-SHA256. Since I
think I'm the only one with code for that (is that right?) and
it just changes a name that doesn't affect bits on the wire
I think that's ok & will do it unless someone speaks up here
in the next short while.

The other one was a question as to whether we should have an
IANA registry for LTP extension types. I'll send a separate
mail on that, since the same remark could be made for the BP
as well & it might warrant a bit of thought. I hope we can
do any required thinking without delaying the LTP specs by
creating a new draft that just has the request to IANA and
the initial values for the registry or registries that we
decide we want. If someone thinks that plan (addressing the
issue via a new draft-irtf-dtnrg-ltp-iana) is problematic
then please reply to this - we can discuss what might go into
the putative draft-irtf-dtnrg-ltp-iana in the other thread
that I'm about to start in a minute...

Regards,
Stephen.