Subject: [dtn-interest] DTNRG meeting in Dublin May 21/22
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Date: Wed, 31 Jan 2007 15:01:10 +0000
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Hi,

We're planning to hold a meeting of DTNRG here in Trinity College
Dublin [1] on May 21/22 this year. The agenda is TBD but will
include all the usual slots. I think we also wanted to try make
some progress on routing if we can, but feel free to suggest
other topics.

So:

1. Keep the dates;
2. Can you let me know (off-list) if you intend attending and
    any special requests that might apply (e.g. if you're coming
    in earlier in the weekend)
3. If you already know you'd like a speaking slot at the meeting,
    let me know (again, off-list) roughly how long you'd like and
    what you might be saying.

Once I've got a feel for numbers etc. I'll send more information.

Thanks,
Stephen.

PS: For those that like sport there'll be Gaelic football [2] matches
on in Croke Park [3] on the Sunday - if a bunch of us are interested
I can arrange something for that.

[1] http://www.tcd.ie/
[2] http://www.youtube.com/watch?v=NHVMca7COv8&mode=related&search=
[3] http://www.crokepark.ie/

Date: Wed, 31 Jan 2007 13:05:55 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Re: Special session / IWSSC
Sender: [email-masked]

FYI.

(Note; You do not have to like that Mozart liqueur:-)

Regards,
Stephen.

-------

International Workshop on Satellite and Space Communications 2007
IWSSC'2007

13-14 September 2007 - Salzburg - Austria

http://iwssc2007.sbg.ac.at/

Special session "Delay Tolerant Networking via Satellites"

We are seeking high-quality papers on delay tolerant networking and related
technologies applied to space communications.

Applications fields for DTN are:
* Deep space communication
* Sensor networks via satellites
* Satellite based disaster recovery communication
* Satellite based sparse mobile networks
and others

Possible topics are:
* Store and forward routing
* Multicasting in degraded conditions
* Convergence layers
* Security services without TTP
* Adaptive coding
* DTN on unidirectional links
and others

Contact: [email-masked]

Submission will proceed through EDAS
(A dedicated track on "Delay Tolerant Networking via Satellites"
will open from March 20 to April 1).

Additional information on how to submit will
be published on the workshop web site.

Thank you for submitting to IWSSC'07

Date: Sun, 28 Jan 2007 13:32:34 +0000
From: Stephen Farrell <[email-masked]>
To: Sally Floyd <[email-masked]>
CC: DTN <[email-masked]>
Subject: [dtn-interest] Re: [IRSG] Looking for reviewers for dtnrg's bundle protocol spec...
Sender: [email-masked]

Thanks Sally,

I'll try get the authors to make this change,

Cheers,
Stephen.

Sally Floyd wrote:
> Stephen -
> 
>>> Section 3.3:
>>> "The significance of the values in all currently defined positions of
>>> this bit string, in order from least-significant position (labeled
>>> '1') to most-significant (labeled '21'), are described here." ->
>>> "The Bundle Processing Control Flags field is described here
>>> (starting with the least-significant bit position, labeled '1') ."
>>> Even better would be a graphic:
>>>    0                          1                             2
>>>    1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1
>>>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>>>   |  General flags     |  Class of Service  |   Status Report    |
>>>   |                    |                    |   Request Flags    |
>>>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>>> (Or for better formatting:  (Though the graphic could look better 
>>> labeling the
>>> least significant bit as '0' instead of '1'.)
> 
> This is just a correction on my earlier email from late December.
> I think that a graphic would be good, but  the standard graphic for
> IP headers is as follows, from RFC 791:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |Version|  IHL  |Type of Service|          Total Length         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> with the leftmost bit the most significant bit.  So it would be good to use
> this convention in this draft also.
> 
> - Sally
> 
> 
> 
> 
> - Sally
> http://www.icir.org/floyd/
> 

Date: Fri, 26 Jan 2007 23:22:55 +0100
From: Damien Sauveron <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] [WISTP2007] Deadline extended to February 1st
Sender: [email-masked]

Due to several requests, the deadline is extended to February 1st (firm
deadline)

*******************************************************************
We apologize in advance if you receive multiple copies of this CFP.
Please disseminate it to your colleagues that could be interested.
*******************************************************************

Workshop in Information Security Theory and Practices 2007: Smart Cards,
Mobile and Ubiquitous Computing Systems
                                  &&
A networking meeting to discuss proposals for the EU FP7

Heraklion, Crete, Greece
May 9-11, 2007

Workshop URL: http://wistp2007.xlim.fr/

*******************************************************
WISTP2007 is:
- Co-Sponsored by IFIP TC6 Communications Systems
- Co-Sponsored by IFIP WG 8.8 Smart Cards
- Co-Sponsored by IFIP WG 11.2 Small System Security
- Co-Sponsored by The British Computer Society
- In Cooperation with the IEEE Computer Society, Technical Committee on
Security and Privacy (TCSP)
- In Cooperation with the IEEE Computer Society, Task Force on
Information Assurance (TFIA)
- In Cooperation with the IEEE Systems, Man, and Cybernetics Society,
Technical Committee on Information Assurance & Intelligent
Multimedia-Mobile Communications
- In Cooperation with the IEEE Systems, Man, and Cybernetics Society,
Technical Committee on Systems Safety and Security
- In Cooperation with the IEEE Vehicular Technology Society
- Supported by the IEEE France Section
- Supported by the IEEE UKRI Section & by the IEEE UKRI Section - Computer
Society Chapter
- Supported by the IEEE Greece Section - Communications Society & Computer
Society & VT&AESS Chapters
- Supported by the EuroSys (European ACM SIGOPS Chapter)
- Supported by the ASF (French ACM SIGOPS Chapter)
- Supported by the Greek Computer Society
- Supported by the ASTI
- Supported by the Institute for Systems and Technologies of
Information, Control and Communication (INSTICC)
- Supported by the SEE
- Supported by the GDR CNRS ASR
- Supported by the VDE ITG

*******************************************************
WISTP2007 Background and Goals:
With the rapid technological development of information technologies,
computer systems and especially embedded systems are becoming more
mobile and ubiquitous, increasingly interfacing with the physical world.
Ensuring  the security of these complex and yet, resource constraint
systems has emerged as one of the most pressing challenges.
The aim of this first workshop is to bring together researchers and
practitioners in related areas and to encourage interchange and
cooperation between the research community and the industrial/consumer
community.
The workshop will consist of technical paper presentations, one special
session for student papers and five invited talks.
To contribute to the structuring of the community, a networking meeting
to discuss EU FP7 projects proposals will take place just after the
workshop.

*******************************************************
Topics of interest include, but are not limited to:

A. Smart Cards and Trusted Devices Security

     * Biometrics, National ID cards
     * Embedded Systems Security and TPMs
     * Interplay of TPMs and Smart Cards
     * New Applications for Secure RFID Systems
     * RFID Systems Security
     * Smart Card Security
     * Smart Card Applications

B. Ad Hoc and Mobile Networks Security

     * Ad Hoc Networks Security
     * Delay-Tolerant Network Security
     * Domestic Network Security
     * Mobile Codes Security
     * Mobile Devices Security
     * Security Issues in Mobile and Ubiquitous Networks
     * Security of GSM/GPRS/UMTS Systems
     * Sensor Networks Security
     * Vehicular Network Security
     * Wireless Communication Security (WiFi, WiMAX, WiMedia, others)

C. Ubiquitous Computing Systems Security

     * Distributed Systems Security
     * Grid Computing Security
     * Intrusion Detection and Information Filtering
     * Peer-to-Peer Networks Security

D. Security Protocols, Policies and Management for Mobility

     * Critical Infrastructure (e.g. for Medical or Military
Applications) Security
     * Digital Rights Management (DRM)
     * Industrial and Multimedia  Applications
     * Information Assurance
     * Localization Systems Security (Tracking of People and Goods)
     * New Applications of Secure Systems
     * Public Administration and Governmental Services
     * Security Models and Architecture
     * Security Policies (Human-Computer Interaction and Human Behavior
Impact)
     * Security Protocols (for Identification and Authentication,
Confidentiality and Privacy, and Integrity)
     * Security Measurements
     * Trust Management

*******************************************************
Submission Details:
Authors are invited to submit original papers (written in english) not
previously published nor submitted in parallel for publication to any
other conference, workshop or journal. All submissions will be subjected
to thorough blind review by at least three reviewers (if the paper
involved a Program Committee member, the paper will be reviewed at least
by five reviewers). All submitted papers should be anonymous with no
author(s) names, affiliations, acknowledgments, nor obvious references.
Each paper should begin with a title, a short abstract, and a list of
keywords, following the template indicated by Springer at:
http://www.springer.de/comp/lncs/authors.html
The papers will be in .pdf format, at most 10 pages long excluding
bibliography and well-marked appendices, and at most 14 pages long in
total, using at least 11-point fonts with reasonable margins. As the
reader should not be required to read any appendices, the paper should
be intelligible even without them.
20 papers will be accepted for presentation at the workshop (they will
be included in the proceedings) and 12 additional papers will be
selected to be presented as A1 poster at the workshop (they will NOT be
included in the proceedings).
If a submitted paper is mainly the result of the work of a student
author, this paper could have the chance to be selected as "Best student
paper" (even if the paper has been written with senior co-authors).
To participate to this selection process, please add the word "STUDENT"
in the affiliation field in the submission form.
At least one author of each accepted paper is required to register with
the Conference and present the paper. For authors presenting multiple
papers, one normal registration is valid for up to two papers.
For electronic paper submission please use the following URL:
https://wistp2007.xlim.fr/wistp2007/iChair/

*******************************************************
Awards:
     * Best student paper: 400€ + a CD-Rom version of the Handbook of
Information Security
     * Best workshop paper: 400€ + a CD-Rom version of the Handbook of
Information Security
     * Best innovative technology: Gift + a CD-Rom version of the
Handbook of Information Security

Authors of the best works in the Smart Card domain selected by the PC
co-chairs of the international conference Cardis'2008 (François-Xavier
Standaert, Gilles Grimaud) will be encouraged to submit extended and
significantly revised versions at Cardis'2008.

Some accepted papers written by French-speaking authors will be
published in a journal of the SEE (in a french version).

*******************************************************
Important Dates:
- Intention of submission: ASAP. Send a mail to [email-masked]
- Intention of attendance: ASAP. Send a mail to [email-masked]
- Paper submission:     February 1st, 2007 (23h59 UTC) - firm -
- Notification:         March 1st, 2007
- Author Registration:  March 3rd, 2007
- Camera-ready papers:  March 5th, 2007

*******************************************************
WISTP2007 Committees and Chairs:

- Workshop Organization Chair:
   Damien Sauveron. XLIM, University of Limoges, France

- Workshop Organizing Committee:
   Angelos Bilas. FORTH-ICS & University of Crete, Greece
   Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of
London, UK
   Damien Sauveron. XLIM, University of Limoges, France

- Workshop co-chairs:
   Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium
   Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of
London, UK

- Workshop Program Committee:
   François Arnault. XLIM, University of Limoges, France
   Angelos Bilas. FORTH-ICS & University of Crete, Greece
   Christophe Bidan, SSIR, Supélec, France
   Pierre-François Bonnefoi. XLIM, University of Limoges, France
   Serge Chaumette. LaBRI, University Bordeaux 1, France
   Pierre Dusart. XLIM, University of Limoges, France
   Eduardo Fernández-Medina Patón. Alarcos Research Group, University of
Castilla-La Mancha, Spain
   Theodoulos Garefalakis, Department of Mathematics, University of
Crete, Greece
   Dieter Gollmann. Security in Distributed Applications, Institutes of
the TU Hamburg-Harburg, Germany
   Stefanos Gritzalis. Info-Sec-Lab, University of the Aegean, Greece
   Olivier Heen. Security Laboratory, Thomson R&D, France
   Sokratis Katsikas. Info-Sec-Lab, University of the Aegean, Greece
   Javier Lopez. Computer Science Department, University of Malaga, Spain
   Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of
London, UK
   Evangelos P. Markatos. FORTH-ICS & University of Crete, Greece
   Fabio Martinelli. Information Security Group,  IIT-CNR, Italy
   Keith Mayes. ISG-SCC, Royal Holloway University of London, UK
   Jan de Meer. smartspacelab.eu, Brandenburg Technical University
(BTU), Germany
   Pierre Paradinas. CEDRIC, CNAM, France
   Kenny Paterson. ISG, Royal Holloway University of London, UK
   Joachim Posegga, Security in Distributed Systems, University of
Hamburg, Germany
   Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium
   Pierangela Samarati. Department of Information Technologies,
University of Milan, Italy
   Damien Sauveron. XLIM, University of Limoges, France
   Paulo Jorge Esteves Veríssimo, LASIGE, University of Lisboa, Portugal

*******************************************************
Keynote Speakers:
- Professor Fred Piper, ISG (Information Security Group), Royal Holloway
University of London, UK
- Professor Jean-Pierre Hubaux, LCA ( Laboratory for computer Communications
and Applications), EPFL, Switzerland
- Stephanie Manning, Chief Engineer, Research and Development, Vodafone
Group Services Limited
- TBA

*******************************************************
Opportunities for students:
To help the students looking for a PhD thesis or a postdoctoral
position, we will propose them to add a colorized sticker on their
badge. In the same way, we will propose to persons offering these
positions to add a sticker with a different color. We hope this
mechanism will help to support the exchanges between young and senior
researchers.

*******************************************************
Thanks to our main sponsors:
Crisp Telecom
Eurosmart
Elopsys
Limousin Expansion
Nokia
Vodafone
WILEY

*******************************************************
We hope you will be interested by this event.
For further inquiries, please contact the secretariat at
[email-masked]

Best regards,
-- 
Damien Sauveron

Date: Tue, 23 Jan 2007 10:09:57 +0200
From: Joerg Ott <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] WoWMoM 2007: Call for Demos
Sender: [email-masked]

Call for Demos
==============

http://ieee-wowmom.tml.hut.fi/

Submission deadline: 28 February 2007

The demo track of IEEE WoWMoM 2007 solicits demonstrations in the world
of wireless, mobile, and multimedia communications. We are looking for
demonstrations of recent or ongoing research work that will showcase the
research and inspire discussion and interaction with the attendees at
WoWMoM 2007. We invite participation from both academia and industry
demonstrating novel research results.

Demonstrations will be presented in a designated demonstration slot in
the conference program. The number of demos presented will be kept low
in order to allow the full attention of the conference participants.

WoWMoM 2007 will have a "Best Demo Award" based upon both the technical
contribution and the demonstrator "showcase".

Topics of interest include, but are not limited to:

     * System prototypes and experiences
     * QoS for voice and video in wireless networks
     * IP-based wireless multimedia applications and systems
     * Multimedia multicasting and broadcasting
     * Handoff and mobility management
     * Seamless internetworking and self-organization
     * Network management and control
     * Context-aware wireless multimedia applications
     * Location mechanism and services
     * Content management and distribution
     * Multimedia applications and systems in vehicular, mesh,
       and ad-hoc networks

Demo proposals shall be short papers of no more than 3 pages (IEEE
conference template, font size no less than 10pt) which will be reviewed
by the Program Committee. The proposals should introduce the background,
describe the key contributions of the author(s), and state what the
demonstrator will show.

A one-page appendix shall provide a comprehensive description of the
demonstration and list all the technical requirements such as equipment
(to be brought by the presenters) and other resources (such as # WLAN
channels, Internet access, etc.), and also include a description of the
demo presentation, e.g., are visitors involved, is a prototype presented
that can be used by visitors, etc.

The short papers of the accepted demo proposals will be included as a
conference supplement, published by IEEE. It serves to inform the
audience of the details behind the demo, and as a permanent record of
the demo. Both the short paper and appendix must be submitted as a
single PDF document by 28 February 2007.

Important Dates:

     * Submission deadline: 28 February 2007
     * Acceptance Notification: 20 March 2007
     * Camera ready deadline: 15 April 2007
     * Conference date: 18-21 June 2007

Paper submission will be handled through EDAS:
http://www.edas.info/newPaper.php?c=5262.

Jörg Ott and James Scott
IEEE WoWMoM 2007 demo chairs

Date: Tue, 23 Jan 2007 08:52:45 +0100
From: Luciana Pelusi <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Extended Deadline: [IEEE WoWMoM'07] CFP Autonomic and Opportunistic Communications (AOC),Workshop  (Deadline: February 11, 2007)
Sender: [email-masked]

  We apologize in advance if you receive multiple copies of this CFP
********************************************************************

                           *CALL FOR PAPERS*

                     First IEEE WoWMoM Workshop on

    *** AUTONOMIC and OPPORTUNISTIC COMMUNICATIONS - AOC 2007 ***
                   June 18, 2007 - Helsinki, Finland
                     http://cnd.iit.cnr.it/aoc2007/

                             organized by
                       *ANA and HAGGLE projects*
              funded by the FET-IST Programme in the area
              Situated and Autonomic Communications (SAC)

         **** *EXTENDED Deadline --- February 11, 2007* ****

********************************************************************

We are faced with an era where the widespread use of small portable
wireless devices and wireless technologies are building the pervasive
vision. This pervaded world has generated new communication paradigms:
autonomic and opportunistic communications.
  Communication among devices in a pervasive environment can happen if
the devices can communicate autonomously, and manage their own evolution
and configuration changes in the network, without explicit user or
administrator action. In a pervasive world, even in the absence of any
connectivity infrastructure mobile devices can communicate using the
connection "opportunities" that arise due to mobility.
  The goal of this workshop is to provide a forum between the autonomic
and opportunistic communication communities to exchange ideas, discuss
solutions, and share experiences among researchers, professionals, and
application developers both from industry and academia. Original papers
addressing both theoretical and practical aspects of autonomic
communications and computing are solicited. Papers describing prototype
implementations and deployment are particularly welcome.

Topics of interest include but are not limited to:

* Architecture and models for autonomic and opportunistic communications
* Tools and techniques for designing, analyzing and building autonomic
and opportunistic networks
* Adaptive security for self protection of networks
* Economic, biological and social models used for autonomic and
opportunistic communications
* Mobility models for opportunistic networking
* Novel management techniques for autonomic and opportunistic communications
* Sensing, monitoring and measurements for self-managing networks
* Advanced technologies for enabling autonomic and opportunistic
communications
* Autonomic and opportunistic communication testbeds and measurements

PAPER SUBMISSION AND PUBLICATION
=================================
Papers should neither have been published elsewhere nor currently
under review by another conference or journal.  Guidelines on paper
submission and formatting are available at http://cnd.iit.cnr.it/aoc2007/.
Accepted papers will appear in the symposium proceedings published by
IEEE. Extended versions of workshop selected papers will be considered
for possible fast track publication on the Pervasive and Mobile
Computing Journal (Elsevier).

IMPORTANT DATES
===============
Full papers due:        *February 11, 2007 (Extended)*
			
Notification:           March 15, 2007

ORGANIZING COMMITTEE
====================

WORKSHOP Chairs:
  Marco Conti, IIT-CNR, Italy
  Silvia Giordano, SUPSI, Switzerland
  Ioannis Stavrakakis, University of Athens, Greece

PUBLICITY Chair:
  Luciana Pelusi, IIT-CNR, Italy

PROGRAM COMMITTEE
  Giuseppe Anastasi, University of Pisa, Italy
  Stefano Basagni, Northeastern University, USA
  Edoardo Biagioni, University of Hawaii, USA
  Levente Buttyan, BUTE, Hungary
  Tracy Camp, Colorado School of Mines, USA
  Augustin Chaintreau, Thomson, France
  Ling-Jyh Chen, Academia Sinica, Taiwan
  Jon Crowcroft, University of Cambridge, UK
  Murat Demirbas, SUNY Buffalo, USA
  Spyros Denazis, Hitachi Europe, France & University of Patras, Greece
  Mohamed Eltoweissy, Virginia Tech., USA
  Mario Gerla, UCLA, USA
  Per Gunningberg, Uppsala University, Sweden
  Vincent Lenders, ETH, Switzerland
  Cecilia Mascolo, UCL, UK
  Martin May, ETH, Switzerland
  Daniele Miorandi, Create-net, Italy
  Refik Molva, Eurécom, France
  Konstantinos Oikonomou, Ionian University, Greece
  Joerg Ott, HUT, Finland
  Andrea Passarella, IIT-CNR, Italy
  Kaustubh Phanse, Uppsala University, Sweden
  George Polyzos, AUEB, Greece
  Chunming Qiao, SUNY Buffalo, USA
  Kave Salamatian, EPFL, Switzerland
  Fabrizio Sestini, FET, European Commission
  Violet Syrotiuk, Arizona State University, USA
  John Vicente, Intel, USA
  Hongyi Wu, University of Louisiana, USA
  Laurence T. Yang, St Francis Xavier University, Canada
  Franco Zambonelli, University of Modena-Reggio, Italy
  Ellen W. Zegura, Georgia Tech, USA

-- 
---------------------------------------------------
Luciana Pelusi
     Ph.D. Student
     Pervasive Computing & Networking Lab. (PerLab)
     www.perlab.it

     Institute for Informatics and Telematics (IIT)
     Italian National Research Council (CNR)
     Via G. Moruzzi, 1 - 56124 Pisa, Italy

     phone: + 39 050 315 3059 (direct)
---------------------------------------------------

From: Kevin Fall <[email-masked]>
Date: Thu, 18 Jan 2007 22:26:32 -0800
To: DTN <[email-masked]>
Subject: [dtn-interest] Fwd: progressing the LTP DTNRG documents (comments by Feb 7 please)
Sender: [email-masked]

A couple of days ago I requested the list to begin review of the  
following two LTP docs:

>>>
>>> The two documents are available here:
>>>
>>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-05.txt
>>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp- 
>>> motivation-03.txt
>>>

There is another one to add to the list:

http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp- 
extensions-04.txt

Again, we are trying to collect comments by Feb 7.  Thanks for your  
help!

- Kevin

From: Kevin Fall <[email-masked]>
Date: Wed, 17 Jan 2007 11:21:53 -0800
To: DTN <[email-masked]>
Subject: [dtn-interest] Fwd: [IRSG] fwd: Opportunity to get involved in the NSF FIND research program
Sender: [email-masked]

fyi-- K

Begin forwarded message:

> From: Aaron Falk <[email-masked]>
> Date: January 17, 2007 9:50:04 AM PST  Jan 17, 2007
> To: Internet Research Steering Group <[email-masked]>
> Subject: [IRSG] fwd: Opportunity to get involved in the NSF FIND  
> research program
>
> RG Chairs-
>
> This note represents an opportunity to get involved in the US
> National Science Foundation's collaborative work on designing a
> 'future Internet.'  It seems relevant to many IRTF RGs and I
> encourage you to forward it to your group's mailing list and other
> lists that you feel are relevant.  In other words, participation
> beyond the US academic community is being encouraged.
>
> --aaron
>
> Begin forwarded message:
>
>> From: David Clark <[email-masked]>
>> Date: January 10, 2007 8:08:29 AM PST
>> To: End to End Interest <[email-masked]>
>> Subject: [e2e] Opportunity to get involved in the NSF FIND research
>> program
>>
>> Folks,
>>     Many of you may know that NSF has announced a focus area for
>> research funding called Future Internet Design, or FIND. The idea
>> behind
>> FIND is to bring together interested researchers to discuss options
>> for
>> a future Internet, and to develop integrated proposals for such a
>> network.
>>     NSF understands that there is lots of interesting, relevant work
>> that has been funded from sources other than NSF, and there may be
>> folks
>> who would like to come to the meetings and participate in the  
>> process,
>> on a BYOF (Bring Your Own Funding) basis. You might have funding
>> from a
>> different NSF program, from another funding agency, or from your
>> company. Perhaps you are from a different country with its own  
>> funding
>> mechanisms.
>>     However you are funded, if you are interesting in being part of
>> the
>> intellectual effort, please read the attached announcement, which
>> is an
>> invitation to send in an informal white paper describing what you
>> are up
>> to.
>>     If you can conceive of other ways to build bridges between this
>> FIND
>> program and other research efforts, please send me a message  
>> directly.
>> We are open to other ideas.
>>
>> David Clark (for the FIND Planning Committee)
>>
>> ----
>>
>>
>>    CALL FOR RESEARCH COLLABORATION ON FUTURE INTERNET ARCHITECTURES
>>                IN PARTNERSHIP WITH THE US NSF FIND PROGRAM
>>
>> BACKGROUND
>>
>> Much energy has recently crystallized within the international
>> network research community for developing fresh perspectives on how
>> to architect a single, coherent, global data network. The
>> Internet's unquestionable success at embodying one such
>> architecture has also led over the decades of its operation to
>> unquestionable difficulties with regard to support for some types
>> of functionality and sound operation.
>>
>> As a reflection of this growing community interest, the U.S.
>> National Science Foundation has announced a focus area for
>> networking research called FIND, or Future Internet Design. The
>> agenda of this focus area is to invite the research community to
>> take a long-range perspective, and to consider what our global
>> network of 10 or 15 years should be, and how to build a network
>> that meets the future requirements. (For further information on the
>> FIND program, see NSF solicitation 07-507, available at http://
>> www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf07507.) The
>> research funded by FIND aims to contribute to the emergence of one
>> or more integrated visions of a future network.
>>
>> A vital part of this effort concerns fostering collaboration and
>> consensus-building among researchers working on future global
>> network architecture. To this end, NSF has created a FIND Planning
>> Committee, which is working with NSF to organize a series of
>> meetings among FIND grant recipients structured around activities
>> to identify and refine overarching concepts for a network of the
>> future.
>>
>> A BROADER COMMUNITY
>>
>> NSF recognizes that its efforts at funding research to contribute
>> to a future global network exists within a broader set of efforts
>> with similar goals supported by other agencies, industry, and
>> nations. Accordingly, NSF seeks researchers external to the FIND
>> program itself—but who share a likeminded vision—to participate in
>> the collaboration and consensus-building. NSF particularly welcomes
>> international collaboration—any vision of a future global network
>> will greatly benefit from global participation.
>>
>> To this end, external researchers interested in such participation
>> are invited to submit short white papers describing themselves and
>> their work. Based on evaluation of these white papers, a select
>> number of researchers will be invited to join the FIND meetings and
>> other events, as overall meeting sizes and logistics permit.
>>
>> EXPECTATIONS AND EVALUATION CRITERIA
>>
>> Since the efficacy of FIND meetings is in part a function of their
>> size and coherence, the evaluation of the white papers will focus
>> on certain criteria that are listed below, along with expectations
>> regarding what external participation entails. Naturally,
>> interested parties should take these considerations into account as
>> they write their white papers, and include information in their
>> papers sufficient to allow the FIND program to evaluate the aptness
>> of their participation.
>>
>> • In a few sentences, please describe your research and its
>> intended impact. When possible, include as an attachment (or a URL)
>> a longer description, which if you wish can be something prepared
>> for another purpose (e.g. your original funding proposal or a
>> publication). It will help to limit the supporting material to 15
>> pages or fewer.
>>
>> • Please summarize in the white paper the ways you see your
>> research as being compatible with the objectives of FIND (the URL
>> for the FIND solicitation is included above). Research that accords
>> with the FIND program will generally be based on a long-term vision
>> of future networking, rather than addressing specific near-term
>> problems, and framed in terms of how it might contribute to an
>> overall architecture for a future network.
>>
>> • The FIND meetings have been organized for the benefit of
>> researchers who have already been funded and are actively pursuing
>> their research. Research described in white papers should already
>> be funded. Please describe the means you have available to cover
>> your FIND-related research: the source of funds, their duration,
>> and (roughly) the supported level of effort. Unfortunately, NSF
>> lacks additional funds to financially support your participation in
>> the meetings, so you must be prepared to cover those costs as well.
>> If you are planning to submit a FIND research proposal to the
>> current NeTS solicitation, you should not submit a white paper here
>> based on that research. Successful FIND grant recipients will
>> automatically be invited to join the FIND community.
>>
>> • As one of the goals of FIND is to develop an active community of
>> researchers who over time work increasingly together towards
>> coherent, overall architectural visions, we aim for external
>> participants to likewise become significantly engaged. To this end,
>> you should anticipate (and have resources for) participating in
>> FIND project meetings in an active, sustained fashion.
>>
>> • Your research must not be encumbered by intellectual property
>> restrictions that prevent you from fully discussing your work and
>> its results with the other participants.
>>
>> Please try to limit your white paper to 2 pages. Your white paper
>> (and the supporting research description) will be read by members
>> of the research community, so do not submit anything that you would
>> not reveal to your peers. (White papers are not viewed as formal
>> submissions to NSF.)
>>
>> TIMING AND SUBMISSION
>>
>> You may submit a white paper at any time during the FIND program.
>> Before each scheduled FIND PI meeting, the papers on hand will be
>> reviewed. Meetings are anticipated to occur approximately three
>> times a year, in March, July/August and November. The next FIND
>> meeting is scheduled for March 5/6, 2007, and priority in
>> consideration for that meeting will be given to white papers that
>> are received by Friday, January 19th, 2007.
>>
>> Send your white paper to Darleen Fisher <[email-masked]> and
>> Allison Mankin <[email-masked]> for coordination.
>>
>>
>
>
> _______________________________________________
> IRSG mailing list
> [email-masked]
> http://mailman.isi.edu/mailman/listinfo/irsg
>

Date: Wed, 17 Jan 2007 19:14:49 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] [Fwd: [IRSG] fwd: Opportunity to get involved in the NSF FIND research program]
Sender: [email-masked]

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

FYI.

--------------030209050702090501010809
Content-Type: message/rfc822;
 name*0="[IRSG] fwd: Opportunity to get involved in the NSF FIND research";
 name*1="	program"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="[IRSG] fwd: Opportunity to get involved in the NSF FIND rese";
 filename*1="arch	program"

From: Aaron Falk <[email-masked]>
Date: Wed, 17 Jan 2007 09:50:04 -0800
To: Internet Research Steering Group <[email-masked]>
Subject: [IRSG] fwd: Opportunity to get involved in the NSF FIND research
	program
Sender: [email-masked]

RG Chairs-

This note represents an opportunity to get involved in the US  =

National Science Foundation's collaborative work on designing a  =

'future Internet.'  It seems relevant to many IRTF RGs and I  =

encourage you to forward it to your group's mailing list and other  =

lists that you feel are relevant.  In other words, participation  =

beyond the US academic community is being encouraged.

--aaron

Begin forwarded message:

> From: David Clark <[email-masked]>
> Date: January 10, 2007 8:08:29 AM PST
> To: End to End Interest <[email-masked]>
> Subject: [e2e] Opportunity to get involved in the NSF FIND research  =

> program
>
> Folks,
>     Many of you may know that NSF has announced a focus area for
> research funding called Future Internet Design, or FIND. The idea  =

> behind
> FIND is to bring together interested researchers to discuss options  =

> for
> a future Internet, and to develop integrated proposals for such a  =

> network.
>     NSF understands that there is lots of interesting, relevant work
> that has been funded from sources other than NSF, and there may be  =

> folks
> who would like to come to the meetings and participate in the process,
> on a BYOF (Bring Your Own Funding) basis. You might have funding  =

> from a
> different NSF program, from another funding agency, or from your
> company. Perhaps you are from a different country with its own funding
> mechanisms.
>     However you are funded, if you are interesting in being part of  =

> the
> intellectual effort, please read the attached announcement, which  =

> is an
> invitation to send in an informal white paper describing what you  =

> are up
> to.
>     If you can conceive of other ways to build bridges between this  =

> FIND
> program and other research efforts, please send me a message directly.
> We are open to other ideas.
>
> David Clark (for the FIND Planning Committee)
>
> ----
>
>
>    CALL FOR RESEARCH COLLABORATION ON FUTURE INTERNET ARCHITECTURES
>                IN PARTNERSHIP WITH THE US NSF FIND PROGRAM
>
> BACKGROUND
>
> Much energy has recently crystallized within the international  =

> network research community for developing fresh perspectives on how  =

> to architect a single, coherent, global data network. The  =

> Internet's unquestionable success at embodying one such  =

> architecture has also led over the decades of its operation to  =

> unquestionable difficulties with regard to support for some types  =

> of functionality and sound operation.
>
> As a reflection of this growing community interest, the U.S.  =

> National Science Foundation has announced a focus area for  =

> networking research called FIND, or Future Internet Design. The  =

> agenda of this focus area is to invite the research community to  =

> take a long-range perspective, and to consider what our global  =

> network of 10 or 15 years should be, and how to build a network  =

> that meets the future requirements. (For further information on the  =

> FIND program, see NSF solicitation 07-507, available at http:// =

> www.nsf.gov/publications/pub_summ.jsp?ods_key=3Dnsf07507.) The  =

> research funded by FIND aims to contribute to the emergence of one  =

> or more integrated visions of a future network.
>
> A vital part of this effort concerns fostering collaboration and  =

> consensus-building among researchers working on future global  =

> network architecture. To this end, NSF has created a FIND Planning  =

> Committee, which is working with NSF to organize a series of  =

> meetings among FIND grant recipients structured around activities  =

> to identify and refine overarching concepts for a network of the  =

> future.
>
> A BROADER COMMUNITY
>
> NSF recognizes that its efforts at funding research to contribute  =

> to a future global network exists within a broader set of efforts  =

> with similar goals supported by other agencies, industry, and  =

> nations. Accordingly, NSF seeks researchers external to the FIND  =

> program itself=97but who share a likeminded vision=97to participate in  =

> the collaboration and consensus-building. NSF particularly welcomes  =

> international collaboration=97any vision of a future global network  =

> will greatly benefit from global participation.
>
> To this end, external researchers interested in such participation  =

> are invited to submit short white papers describing themselves and  =

> their work. Based on evaluation of these white papers, a select  =

> number of researchers will be invited to join the FIND meetings and  =

> other events, as overall meeting sizes and logistics permit.
>
> EXPECTATIONS AND EVALUATION CRITERIA
>
> Since the efficacy of FIND meetings is in part a function of their  =

> size and coherence, the evaluation of the white papers will focus  =

> on certain criteria that are listed below, along with expectations  =

> regarding what external participation entails. Naturally,  =

> interested parties should take these considerations into account as  =

> they write their white papers, and include information in their  =

> papers sufficient to allow the FIND program to evaluate the aptness  =

> of their participation.
>
> =95 In a few sentences, please describe your research and its  =

> intended impact. When possible, include as an attachment (or a URL)  =

> a longer description, which if you wish can be something prepared  =

> for another purpose (e.g. your original funding proposal or a  =

> publication). It will help to limit the supporting material to 15  =

> pages or fewer.
>
> =95 Please summarize in the white paper the ways you see your  =

> research as being compatible with the objectives of FIND (the URL  =

> for the FIND solicitation is included above). Research that accords  =

> with the FIND program will generally be based on a long-term vision  =

> of future networking, rather than addressing specific near-term  =

> problems, and framed in terms of how it might contribute to an  =

> overall architecture for a future network.
>
> =95 The FIND meetings have been organized for the benefit of  =

> researchers who have already been funded and are actively pursuing  =

> their research. Research described in white papers should already  =

> be funded. Please describe the means you have available to cover  =

> your FIND-related research: the source of funds, their duration,  =

> and (roughly) the supported level of effort. Unfortunately, NSF  =

> lacks additional funds to financially support your participation in  =

> the meetings, so you must be prepared to cover those costs as well.  =

> If you are planning to submit a FIND research proposal to the  =

> current NeTS solicitation, you should not submit a white paper here  =

> based on that research. Successful FIND grant recipients will  =

> automatically be invited to join the FIND community.
>
> =95 As one of the goals of FIND is to develop an active community of  =

> researchers who over time work increasingly together towards  =

> coherent, overall architectural visions, we aim for external  =

> participants to likewise become significantly engaged. To this end,  =

> you should anticipate (and have resources for) participating in  =

> FIND project meetings in an active, sustained fashion.
>
> =95 Your research must not be encumbered by intellectual property  =

> restrictions that prevent you from fully discussing your work and  =

> its results with the other participants.
>
> Please try to limit your white paper to 2 pages. Your white paper  =

> (and the supporting research description) will be read by members  =

> of the research community, so do not submit anything that you would  =

> not reveal to your peers. (White papers are not viewed as formal  =

> submissions to NSF.)
>
> TIMING AND SUBMISSION
>
> You may submit a white paper at any time during the FIND program.  =

> Before each scheduled FIND PI meeting, the papers on hand will be  =

> reviewed. Meetings are anticipated to occur approximately three  =

> times a year, in March, July/August and November. The next FIND  =

> meeting is scheduled for March 5/6, 2007, and priority in  =

> consideration for that meeting will be given to white papers that  =

> are received by Friday, January 19th, 2007.
>
> Send your white paper to Darleen Fisher <[email-masked]> and  =

> Allison Mankin <[email-masked]> for coordination.
>
>

_______________________________________________
IRSG mailing list
[email-masked]
http://mailman.isi.edu/mailman/listinfo/irsg

--------------030209050702090501010809--

Date: Wed, 17 Jan 2007 11:01:21 -0500
From: "Armando L. Caro, Jr." <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] draft-irtf-dtnrg-ltp-motivation-03.txt
OpenPGP: id=A9CE816E
Sender: [email-masked]

Scott Burleigh wrote:

> Stephen's comment is right on the mark here.  Do we need to add some
> such comment to the document?  If this were a protocol spec we'd want to
> say something like "The manner in which this information becomes known
> is beyond the scope of this document", but in a motivational overview
> this seems unduly fussy.

I think you're right. Extra text probably isn't necessary. I just asked
for my own benefit.

> Good catch, except I don't think "session" used in TCP terminology
> either.  How about "a single TCP connection (local host address, local
> port  number, foreign host address, foreign port number) can accommodate
> at most one such thread of retransmission protocol at any one time"?

Yes, that works.

-- 
Armando

Date: Wed, 17 Jan 2007 07:46:00 -0800
From: Scott Burleigh <[email-masked]>
To: "Armando L. Caro, Jr." <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] draft-irtf-dtnrg-ltp-motivation-03.txt
Sender: [email-masked]

Armando L. Caro, Jr. wrote:
> Overall, this draft looks good to me. I do have some basic
> comments/questions though. FYI, I'm reading this draft for the first
> time, which means that I may pick up on ambiguities/subtleties that
> might be missed by others who have seen previous iterations of this draft.
>
> Section 3.1.1 states that each session can only accommodate a single
> data block. However, it is not immediately clear whether this block is
> an application PDU or transport PDU. Section 3.1.2 clears that up by
> stating that application data blocks can be broken into segments.
> Perhaps this should be cleared up immediately at the end of Section
> 3.1.1's 2nd paragraph.
>   
Right, let's just change "a single block of data" to "a single block of 
application data".
> Section 3.6. The first stage of RTT estimation uses "the known one-way
> light time to the destination". How is this information known/acquired?
>   
Stephen's comment is right on the mark here.  Do we need to add some 
such comment to the document?  If this were a protocol spec we'd want to 
say something like "The manner in which this information becomes known 
is beyond the scope of this document", but in a motivational overview 
this seems unduly fussy.
> ----
> Nit picks:
>
> Last paragraph in Section 2. "The SCTP [SCTP] protocol can multiplex
> bundles..."  SCTP doesn't use 'bundle' in its terminology. The correct
> term is 'chunk'. So the Note in ()'s can be removed too.
>   
Fine.
> Same paragraph. I would suggest adding "(association in SCTP
> terminology)" after "single layer connection".
>   
Sure.
> I followed the text when referring to TCP associations & connections,
> and LTP associations & sessions. However, it might be confusing to
> others if the correct terminology isn't used. TCP terminology doesn't
> use the term "associations". So I would change Section 3.1.1, paragraph
> 3, sentence 1 to:
>
>    "However, a single TCP connection (local host address, local port
>    number, foreign host address, foreign port number) can accommodate at
>    most one session at any one time."
>
> Similar change for first sentence in Section 3.1.2.
>   
Good catch, except I don't think "session" used in TCP terminology 
either.  How about "a single TCP connection (local host address, local 
port  number, foreign host address, foreign port number) can accommodate 
at most one such thread of retransmission protocol at any one time"?

Scott

Date: Wed, 17 Jan 2007 13:55:51 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] Adding a sentence to the abstract of draft-irtf-dtnrg-arch...
Sender: [email-masked]

Folks,

In order to further smooth the path of the arch document, it
would help if we ask the RFC editor to add the following to
the abstract:

"This document represents the consensus of the IRTF DTN
research group and has been widely reviewed by that group."

If anyone objects to that, please say so now, (well, before
Feb 13), cc'-ing this list and Lars Eggert, who's the IESG AD
who's handling the rfc 3932 review for the document.

Otherwise, I'll (or Lars will, I'm not sure) include an RFC
editor note with the document requesting the addition of that
sentence.

Thanks,
Stephen.

Date: Wed, 17 Jan 2007 10:15:05 +0000
From: Stephen Farrell <[email-masked]>
To: "Armando L. Caro, Jr." <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] draft-irtf-dtnrg-ltp-motivation-03.txt
Sender: [email-masked]

Hi Armando,

I think all those are good changes to make. One clarification
in-line,

Thanks,
S.

Armando L. Caro, Jr. wrote:
> Overall, this draft looks good to me. I do have some basic
> comments/questions though. FYI, I'm reading this draft for the first
> time, which means that I may pick up on ambiguities/subtleties that
> might be missed by others who have seen previous iterations of this draft.
> 
> Section 3.1.1 states that each session can only accommodate a single
> data block. However, it is not immediately clear whether this block is
> an application PDU or transport PDU. Section 3.1.2 clears that up by
> stating that application data blocks can be broken into segments.
> Perhaps this should be cleared up immediately at the end of Section
> 3.1.1's 2nd paragraph.
> 
> Section 3.6. The first stage of RTT estimation uses "the known one-way
> light time to the destination". How is this information known/acquired?

Generally from some complicated ephemeris setup. But the complexity can
be well hidden. There's a nice library (from, I think JPL) that does
this for you, given a nice data file (same source). Check out [1],
though its a long while since I downloaded a version of their code,
so much may have changed. If you were using LTP in a terrestrial
application, then you'd probably use zero here (or maybe 200ms or
something).

	[1] http://www.ephemeris.com/

> 
> ----
> Nit picks:
> 
> Last paragraph in Section 2. "The SCTP [SCTP] protocol can multiplex
> bundles..."  SCTP doesn't use 'bundle' in its terminology. The correct
> term is 'chunk'. So the Note in ()'s can be removed too.
> 
> Same paragraph. I would suggest adding "(association in SCTP
> terminology)" after "single layer connection".
> 
> I followed the text when referring to TCP associations & connections,
> and LTP associations & sessions. However, it might be confusing to
> others if the correct terminology isn't used. TCP terminology doesn't
> use the term "associations". So I would change Section 3.1.1, paragraph
> 3, sentence 1 to:
> 
>    "However, a single TCP connection (local host address, local port
>    number, foreign host address, foreign port number) can accommodate at
>    most one session at any one time."
> 
> Similar change for first sentence in Section 3.1.2.
> 

Date: Tue, 16 Jan 2007 17:49:09 -0500
From: "Armando L. Caro, Jr." <[email-masked]>
To: DTN <[email-masked]>
OpenPGP: id=A9CE816E
Subject: [dtn-interest] draft-irtf-dtnrg-ltp-motivation-03.txt
Sender: [email-masked]

Overall, this draft looks good to me. I do have some basic
comments/questions though. FYI, I'm reading this draft for the first
time, which means that I may pick up on ambiguities/subtleties that
might be missed by others who have seen previous iterations of this draft.

Section 3.1.1 states that each session can only accommodate a single
data block. However, it is not immediately clear whether this block is
an application PDU or transport PDU. Section 3.1.2 clears that up by
stating that application data blocks can be broken into segments.
Perhaps this should be cleared up immediately at the end of Section
3.1.1's 2nd paragraph.

Section 3.6. The first stage of RTT estimation uses "the known one-way
light time to the destination". How is this information known/acquired?

----
Nit picks:

Last paragraph in Section 2. "The SCTP [SCTP] protocol can multiplex
bundles..."  SCTP doesn't use 'bundle' in its terminology. The correct
term is 'chunk'. So the Note in ()'s can be removed too.

Same paragraph. I would suggest adding "(association in SCTP
terminology)" after "single layer connection".

I followed the text when referring to TCP associations & connections,
and LTP associations & sessions. However, it might be confusing to
others if the correct terminology isn't used. TCP terminology doesn't
use the term "associations". So I would change Section 3.1.1, paragraph
3, sentence 1 to:

   "However, a single TCP connection (local host address, local port
   number, foreign host address, foreign port number) can accommodate at
   most one session at any one time."

Similar change for first sentence in Section 3.1.2.

-- 
Armando
www.armandocaro.net

From: Kevin Fall <[email-masked]>
Date: Tue, 16 Jan 2007 12:53:48 -0800
To: DTN <[email-masked]>
Subject: [dtn-interest] Fwd: progressing the LTP DTNRG documents (comments by Feb 7 please)
Sender: [email-masked]

Another re-send.  Evidently I had the wrong new email address...  
anyhow, here it is.  -K

> From: Kevin Fall <[email-masked]>
> Date: January 16, 2007 12:42:39 PM PST  Jan 16, 2007
> To: DTN <[email-masked]>
> Subject: Fwd: progressing the LTP DTNRG documents (comments by Feb  
> 7 please)
>
> This is a re-send; I was told it never quite made it to the list  
> (which is possible given that I have been changing around my email  
> life recently).
>
> - K
>
> Begin forwarded message:
>
>> From: Kevin Fall <[email-masked]>
>> Date: January 12, 2007 9:00:10 AM PST  Jan 12, 2007
>> To: DTN <[email-masked]>
>> Subject: progressing the LTP DTNRG documents (comments by Feb 7  
>> please)
>>
>>
>> Greetings and happy new year.
>>
>> We would like to progress two of the DTNRG LTP-related documents  
>> toward RFCs.  The first step in this process is to obtain  
>> consensus among members of the research group to go forward.
>>
>> The two documents are available here:
>>
>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-05.txt
>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp- 
>> motivation-03.txt
>>
>> Please have a look at these documents and provide comments back to  
>> the list.  We would like to receive any comments by Feb 7.
>>
>> Thanks,
>> - Kevin
>>
>

Date: Sun, 14 Jan 2007 12:14:07 +0100
From: Damien Sauveron <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] [WISTP2007] Third Call for Papers
Sender: [email-masked]

*******************************************************************
We apologize in advance if you receive multiple copies of this CFP.
Please disseminate it to your colleagues that could be interested.
*******************************************************************

Workshop in Information Security Theory and Practices 2007: Smart Cards,
Mobile and Ubiquitous Computing Systems
                                  &&
A networking meeting to discuss proposals for the EU FP7

Heraklion, Crete, Greece
May 9-11, 2007

Workshop URL: http://wistp2007.xlim.fr/

*******************************************************
WISTP2007 is:
- Co-Sponsored by IFIP TC6 Communications Systems
- Co-Sponsored by IFIP WG 8.8 Smart Cards
- Co-Sponsored by IFIP WG 11.2 Small System Security
- Co-Sponsored by The British Computer Society
- In Cooperation with the IEEE Computer Society, Technical Committee on
Security and Privacy (TCSP)
- In Cooperation with the IEEE Computer Society, Task Force on
Information Assurance (TFIA)
- In Cooperation with the IEEE Systems, Man, and Cybernetics Society,
Technical Committee on Information Assurance & Intelligent
Multimedia-Mobile Communications
- In Cooperation with the IEEE Systems, Man, and Cybernetics Society,
Technical Committee on Systems Safety and Security
- In Cooperation with the IEEE Vehicular Technology Society
- Supported by the IEEE France Section
- Supported by the IEEE UKRI Section & by the IEEE UKRI Section - Computer
Society Chapter
- Supported by the IEEE Greece Section - Communications Society & Computer
Society & VT&AESS Chapters
- Supported by the EuroSys (European ACM SIGOPS Chapter)
- Supported by the ASF (French ACM SIGOPS Chapter)
- Supported by the Greek Computer Society
- Supported by the ASTI
- Supported by the Institute for Systems and Technologies of
Information, Control and Communication (INSTICC)
- Supported by the SEE
- Supported by the GDR CNRS ASR
- Supported by the VDE ITG

*******************************************************
WISTP2007 Background and Goals:
With the rapid technological development of information technologies,
computer systems and especially embedded systems are becoming more
mobile and ubiquitous, increasingly interfacing with the physical world.
Ensuring  the security of these complex and yet, resource constraint
systems has emerged as one of the most pressing challenges.
The aim of this first workshop is to bring together researchers and
practitioners in related areas and to encourage interchange and
cooperation between the research community and the industrial/consumer
community.
The workshop will consist of technical paper presentations, one special
session for student papers and five invited talks.
To contribute to the structuring of the community, a networking meeting
to discuss EU FP7 projects proposals will take place just after the
workshop.

*******************************************************
Topics of interest include, but are not limited to:

A. Smart Cards and Trusted Devices Security

     * Biometrics, National ID cards
     * Embedded Systems Security and TPMs
     * Interplay of TPMs and Smart Cards
     * New Applications for Secure RFID Systems
     * RFID Systems Security
     * Smart Card Security
     * Smart Card Applications

B. Ad Hoc and Mobile Networks Security

     * Ad Hoc Networks Security
     * Delay-Tolerant Network Security
     * Domestic Network Security
     * Mobile Codes Security
     * Mobile Devices Security
     * Security Issues in Mobile and Ubiquitous Networks
     * Security of GSM/GPRS/UMTS Systems
     * Sensor Networks Security
     * Vehicular Network Security
     * Wireless Communication Security (WiFi, WiMAX, WiMedia, others)

C. Ubiquitous Computing Systems Security

     * Distributed Systems Security
     * Grid Computing Security
     * Intrusion Detection and Information Filtering
     * Peer-to-Peer Networks Security

D. Security Protocols, Policies and Management for Mobility

     * Critical Infrastructure (e.g. for Medical or Military
Applications) Security
     * Digital Rights Management (DRM)
     * Industrial and Multimedia  Applications
     * Information Assurance
     * Localization Systems Security (Tracking of People and Goods)
     * New Applications of Secure Systems
     * Public Administration and Governmental Services
     * Security Models and Architecture
     * Security Policies (Human-Computer Interaction and Human Behavior
Impact)
     * Security Protocols (for Identification and Authentication,
Confidentiality and Privacy, and Integrity)
     * Security Measurements
     * Trust Management

*******************************************************
Submission Details:
Authors are invited to submit original papers (written in english) not
previously published nor submitted in parallel for publication to any
other conference, workshop or journal. All submissions will be subjected
to thorough blind review by at least three reviewers (if the paper
involved a Program Committee member, the paper will be reviewed at least
by five reviewers). All submitted papers should be anonymous with no
author(s) names, affiliations, acknowledgments, nor obvious references.
Each paper should begin with a title, a short abstract, and a list of
keywords, following the template indicated by Springer at:
http://www.springer.de/comp/lncs/authors.html
The papers will be in .pdf format, at most 10 pages long excluding
bibliography and well-marked appendices, and at most 14 pages long in
total, using at least 11-point fonts with reasonable margins. As the
reader should not be required to read any appendices, the paper should
be intelligible even without them.
20 papers will be accepted for presentation at the workshop (they will be
included in the proceedings) and 12 additional papers will be selected to
be presented as A1 poster at the workshop (they will NOT be included in
the proceedings).
At least one author of each accepted paper is required to register with
the Conference and present the paper. For authors presenting multiple
papers, one normal registration is valid for up to two papers.
For electronic paper submission please use the following URL:
https://wistp2007.xlim.fr/wistp2007/iChair/

*******************************************************
Awards:
     * Best student paper: 400€ + a CD-Rom version of the Handbook of
Information Security
     * Best workshop paper: 400€ + a CD-Rom version of the Handbook of
Information Security
     * Best innovative technology: Gift + a CD-Rom version of the Handbook
of Information Security

Authors of the best works in the Smart Card domain selected by the PC
co-chairs of the international conference Cardis'2008 (François-Xavier
Standaert, Gilles Grimaud) will be encouraged to submit extended and
significantly revised versions at Cardis'2008.

Some accepted papers written by French-speaking authors will be published
in a journal of the SEE (in a french version).

*******************************************************
Important Dates:
- Intention of submission: ASAP. Send a mail to [email-masked]
- Intention of attendance: ASAP. Send a mail to [email-masked]
- Paper submission:     January 26th, 2007
- Notification:         March 1st, 2007
- Author Registration:  March 3rd, 2007
- Camera-ready papers:  March 5th, 2007

*******************************************************
WISTP2007 Committees and Chairs:

- Workshop Organization Chair:
   Damien Sauveron. XLIM, University of Limoges, France

- Workshop Organizing Committee:
   Angelos Bilas. FORTH-ICS & University of Crete, Greece
   Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of
London, UK
   Damien Sauveron. XLIM, University of Limoges, France

- Workshop co-chairs:
   Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium
   Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of
London, UK

- Workshop Program Committee:
   François Arnault. XLIM, University of Limoges, France
   Angelos Bilas. FORTH-ICS & University of Crete, Greece
   Christophe Bidan, SSIR, Supélec, France
   Pierre-François Bonnefoi. XLIM, University of Limoges, France
   Serge Chaumette. LaBRI, University Bordeaux 1, France
   Pierre Dusart. XLIM, University of Limoges, France
   Eduardo Fernández-Medina Patón. Alarcos Research Group, University of
Castilla-La Mancha, Spain
   Theodoulos Garefalakis, Department of Mathematics, University of
Crete, Greece
   Dieter Gollmann. Security in Distributed Applications, Institutes of
the TU Hamburg-Harburg, Germany
   Stefanos Gritzalis. Info-Sec-Lab, University of the Aegean, Greece
   Olivier Heen. Security Laboratory, Thomson R&D, France
   Sokratis Katsikas. Info-Sec-Lab, University of the Aegean, Greece
   Javier Lopez. Computer Science Department, University of Malaga, Spain
   Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of
London, UK
   Evangelos P. Markatos. FORTH-ICS & University of Crete, Greece
   Fabio Martinelli. Information Security Group,  IIT-CNR, Italy
   Keith Mayes. ISG-SCC, Royal Holloway University of London, UK
   Jan de Meer. smartspacelab.eu, Brandenburg Technical University
(BTU), Germany
   Pierre Paradinas. CEDRIC, CNAM, France
   Kenny Paterson. ISG, Royal Holloway University of London, UK
   Joachim Posegga, Security in Distributed Systems, University of
Hamburg, Germany
   Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium
   Pierangela Samarati. Department of Information Technologies,
University of Milan, Italy
   Damien Sauveron. XLIM, University of Limoges, France
   Paulo Jorge Esteves Veríssimo, LASIGE, University of Lisboa, Portugal

*******************************************************
Keynote Speakers:
- Professor Fred Piper, ISG (Information Security Group), Royal Holloway
University of London, UK
- Professor Jean-Pierre Hubaux, LCA ( Laboratory for computer Communications
and Applications), EPFL, Switzerland
- Stephanie Manning, Chief Engineer, Research and Development, Vodafone
Group Services Limited
- TBA

*******************************************************
Opportunities for students:
To help the students looking for a PhD thesis or a postdoctoral
position, we will propose them to add a colorized sticker on their
badge. In the same way, we will propose to persons offering these
positions to add a sticker with a different color. We hope this
mechanism will help to support the exchanges between young and senior
researchers.

*******************************************************
Thanks to our main sponsors:
Crisp Telecom
Eurosmart
Elopsys
Limousin Expansion
Nokia
Vodafone
WILEY

*******************************************************
We hope you will be interested by this event.
For further inquiries, please contact the secretariat at
[email-masked]

Best regards,
-- 
Damien Sauveron

Cc: Internet Research Steering Group <[email-masked]>, DTN <[email-masked]>, Stephen Farrell <[email-masked]>
From: Aaron Falk <[email-masked]>
Date: Thu, 11 Jan 2007 17:09:55 -0800
To: RFC Editor <[email-masked]>
Subject: [dtn-interest] Request to publish draft-irtf-dtnrg-arch-08 as an IRTF RFC
Sender: [email-masked]

Dear RFC Editor-

Please publish draft-irtf-dtnrg-arch-08 as an Informational IRTF- 
stream RFC.  The IRSG has reviewed this document and approved it for  
publication.  Please include Stephen Farrell  
<[email-masked]> on all correspondence relating to  
publication of this document.  Details of the review process follow  
below.

--Aaron Falk
   IRTF Chair

Begin forwarded message:

> From: Stephen Farrell <[email-masked]>
> Date: January 11, 2007 11:54:45 AM PST
> To: Aaron Falk <[email-masked]>
> Cc: Internet Research Steering Group <[email-masked]>, DTN <dtn- 
> [email-masked]>
> Subject: DTNRG arch document ready to send to RFC editor
>
>
> Hi Aaron,
>
> In accordance with current IRTF processes, the DTNRG arch
> document [1], is now finished IRSG review and ready for you
> to send to the RFC editor.
>
> The tracker ticket [2] for this has links to the various stages of
> the review, including the last entry which links to the "go ahead"
> messages [3,4] from the folks whose comments were addressed in the
> last stage of the review. The original IRSG reviews are [5,6]
> and the RG "please ok" thread is [7].
>
> I'll be shepherd for this document which is intended to become
> an informational RFC.
>
> Regards,
> Stephen.
>
> [1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.txt
> [2] http://www1.tools.ietf.org/group/irtf/trac/ticket/6
> [3] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-December/ 
> 002456.html
> [4] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-January/ 
> 002486.html
> [5] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/ 
> 002173.html
> [6] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/ 
> 002173.html
> [7] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-February/ 
> 002091.html
>

Cc: Internet Research Steering Group <[email-masked]>, DTN <[email-masked]>
From: Aaron Falk <[email-masked]>
Date: Thu, 11 Jan 2007 17:09:28 -0800
To: Kevin Fall <[email-masked]>
Subject: [dtn-interest] Re: [IRSG] DTNRG arch document ready to send to RFC editor
Sender: [email-masked]

Oops!  Thanks.

--aaron

On Jan 11, 2007, at 4:56 PM, Kevin Fall wrote:

> yes (see the last para of Stephen's original email).
>
> - K
>
> On Jan 11, 2007, at 4:15 PM, Aaron Falk wrote:
>
>> And the doc is to be an Informational RFC?
>>
>> --aaron
>>
>> On Jan 11, 2007, at 2:42 PM, Kevin Fall wrote:
>>
>>> iThe disclaimer sounds a little harsh (maybe it should say
>>> 'deployment on the public Internet) but I guess is otherwise right.
>>>
>>> - K
>>>
>>> On Jan 11, 2007, at 1:41 PM, Aaron Falk wrote:
>>>
>>>> Stephen-
>>>>
>>>> Should I assume that you would like the doc to be Informational (as
>>>> opposed to Experimental) and that the IESG use this 'blurb' (see
>>>> draft-irtf-rfcs for the alternative):
>>>>
>>>>       "This RFC is a product of the Internet Research Task Force  
>>>> and
>>>>        is not a candidate for any level of Internet Standard.  The
>>>>        IRTF publishes the results of Internet-related research and
>>>>        development activities.  These results might not be suitable
>>>>        for deployment."
>>>> ?
>>>>
>>>> --aaron
>>>>
>>>> On Jan 11, 2007, at 11:54 AM, Stephen Farrell wrote:
>>>>
>>>>>
>>>>> Hi Aaron,
>>>>>
>>>>> In accordance with current IRTF processes, the DTNRG arch
>>>>> document [1], is now finished IRSG review and ready for you
>>>>> to send to the RFC editor.
>>>>>
>>>>> The tracker ticket [2] for this has links to the various stages of
>>>>> the review, including the last entry which links to the "go ahead"
>>>>> messages [3,4] from the folks whose comments were addressed in the
>>>>> last stage of the review. The original IRSG reviews are [5,6]
>>>>> and the RG "please ok" thread is [7].
>>>>>
>>>>> I'll be shepherd for this document which is intended to become
>>>>> an informational RFC.
>>>>>
>>>>> Regards,
>>>>> Stephen.
>>>>>
>>>>> [1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg- 
>>>>> arch-08.txt
>>>>> [2] http://www1.tools.ietf.org/group/irtf/trac/ticket/6
>>>>> [3] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-December/
>>>>> 002456.html
>>>>> [4] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-January/
>>>>> 002486.html
>>>>> [5] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/
>>>>> 002173.html
>>>>> [6] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/
>>>>> 002173.html
>>>>> [7] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-February/
>>>>> 002091.html
>>>>>
>>>>
>>>> _______________________________________________
>>>> IRSG mailing list
>>>> [email-masked]
>>>> http://mailman.isi.edu/mailman/listinfo/irsg
>>>>
>>
>> _______________________________________________
>> IRSG mailing list
>> [email-masked]
>> http://mailman.isi.edu/mailman/listinfo/irsg
>>

Cc: Stephen Farrell <[email-masked]>, Internet Research Steering Group <[email-masked]>, DTN <[email-masked]>
From: Aaron Falk <[email-masked]>
Date: Thu, 11 Jan 2007 16:15:25 -0800
To: Kevin Fall <[email-masked]>
Subject: [dtn-interest] Re: [IRSG] DTNRG arch document ready to send to RFC editor
Sender: [email-masked]

And the doc is to be an Informational RFC?

--aaron

On Jan 11, 2007, at 2:42 PM, Kevin Fall wrote:

> iThe disclaimer sounds a little harsh (maybe it should say  
> 'deployment on the public Internet) but I guess is otherwise right.
>
> - K
>
> On Jan 11, 2007, at 1:41 PM, Aaron Falk wrote:
>
>> Stephen-
>>
>> Should I assume that you would like the doc to be Informational (as
>> opposed to Experimental) and that the IESG use this 'blurb' (see
>> draft-irtf-rfcs for the alternative):
>>
>>       "This RFC is a product of the Internet Research Task Force and
>>        is not a candidate for any level of Internet Standard.  The
>>        IRTF publishes the results of Internet-related research and
>>        development activities.  These results might not be suitable
>>        for deployment."
>> ?
>>
>> --aaron
>>
>> On Jan 11, 2007, at 11:54 AM, Stephen Farrell wrote:
>>
>>>
>>> Hi Aaron,
>>>
>>> In accordance with current IRTF processes, the DTNRG arch
>>> document [1], is now finished IRSG review and ready for you
>>> to send to the RFC editor.
>>>
>>> The tracker ticket [2] for this has links to the various stages of
>>> the review, including the last entry which links to the "go ahead"
>>> messages [3,4] from the folks whose comments were addressed in the
>>> last stage of the review. The original IRSG reviews are [5,6]
>>> and the RG "please ok" thread is [7].
>>>
>>> I'll be shepherd for this document which is intended to become
>>> an informational RFC.
>>>
>>> Regards,
>>> Stephen.
>>>
>>> [1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.txt
>>> [2] http://www1.tools.ietf.org/group/irtf/trac/ticket/6
>>> [3] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-December/
>>> 002456.html
>>> [4] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-January/
>>> 002486.html
>>> [5] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/
>>> 002173.html
>>> [6] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/
>>> 002173.html
>>> [7] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-February/
>>> 002091.html
>>>
>>
>> _______________________________________________
>> IRSG mailing list
>> [email-masked]
>> http://mailman.isi.edu/mailman/listinfo/irsg
>>

Cc: Stephen Farrell <[email-masked]>, Internet Research Steering Group <[email-masked]>, DTN <[email-masked]>
From: Aaron Falk <[email-masked]>
Date: Thu, 11 Jan 2007 15:41:29 -0800
To: Kevin Fall <[email-masked]>
Subject: [dtn-interest] Re: [IRSG] DTNRG arch document ready to send to RFC editor
Sender: [email-masked]

Kevin-

This is a slightly modified variant of the language in RFC3932 that  
is used for independent submissions.  When we started the IRTF RFC  
stream discussions I negotiated use of this language with the IESG.   
I'm open to finding better words.

If we have a 'blurb' I'd like it to be the same for all documents.   
draft-irtf-rfcs-00.txt has two, one for documents that have been  
introduced to the IETF at some time in the past and another for the  
rest. (See section 2.6 of http://www.irtf.org/chairfiles/draft-irtf- 
rfcs-00.txt)

Ran Atkinson has suggested that we shoot to have the disclaimer  
removed altogether.  Getting the IESG to accept that would require a  
strong push from the community -- e.g, RGs (& chairs).

--aaron

On Jan 11, 2007, at 2:42 PM, Kevin Fall wrote:

> iThe disclaimer sounds a little harsh (maybe it should say  
> 'deployment on the public Internet) but I guess is otherwise right.
>
> - K
>
> On Jan 11, 2007, at 1:41 PM, Aaron Falk wrote:
>
>> Stephen-
>>
>> Should I assume that you would like the doc to be Informational (as
>> opposed to Experimental) and that the IESG use this 'blurb' (see
>> draft-irtf-rfcs for the alternative):
>>
>>       "This RFC is a product of the Internet Research Task Force and
>>        is not a candidate for any level of Internet Standard.  The
>>        IRTF publishes the results of Internet-related research and
>>        development activities.  These results might not be suitable
>>        for deployment."
>> ?
>>
>> --aaron
>>
>> On Jan 11, 2007, at 11:54 AM, Stephen Farrell wrote:
>>
>>>
>>> Hi Aaron,
>>>
>>> In accordance with current IRTF processes, the DTNRG arch
>>> document [1], is now finished IRSG review and ready for you
>>> to send to the RFC editor.
>>>
>>> The tracker ticket [2] for this has links to the various stages of
>>> the review, including the last entry which links to the "go ahead"
>>> messages [3,4] from the folks whose comments were addressed in the
>>> last stage of the review. The original IRSG reviews are [5,6]
>>> and the RG "please ok" thread is [7].
>>>
>>> I'll be shepherd for this document which is intended to become
>>> an informational RFC.
>>>
>>> Regards,
>>> Stephen.
>>>
>>> [1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.txt
>>> [2] http://www1.tools.ietf.org/group/irtf/trac/ticket/6
>>> [3] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-December/
>>> 002456.html
>>> [4] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-January/
>>> 002486.html
>>> [5] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/
>>> 002173.html
>>> [6] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/
>>> 002173.html
>>> [7] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-February/
>>> 002091.html
>>>
>>
>> _______________________________________________
>> IRSG mailing list
>> [email-masked]
>> http://mailman.isi.edu/mailman/listinfo/irsg
>>

Cc: Internet Research Steering Group <[email-masked]>, DTN <[email-masked]>
From: Aaron Falk <[email-masked]>
Date: Thu, 11 Jan 2007 13:41:52 -0800
To: Stephen Farrell <[email-masked]>
Subject: [dtn-interest] Re: DTNRG arch document ready to send to RFC editor
Sender: [email-masked]

Stephen-

Should I assume that you would like the doc to be Informational (as  
opposed to Experimental) and that the IESG use this 'blurb' (see  
draft-irtf-rfcs for the alternative):

      "This RFC is a product of the Internet Research Task Force and
       is not a candidate for any level of Internet Standard.  The
       IRTF publishes the results of Internet-related research and
       development activities.  These results might not be suitable
       for deployment."
?

--aaron

On Jan 11, 2007, at 11:54 AM, Stephen Farrell wrote:

>
> Hi Aaron,
>
> In accordance with current IRTF processes, the DTNRG arch
> document [1], is now finished IRSG review and ready for you
> to send to the RFC editor.
>
> The tracker ticket [2] for this has links to the various stages of
> the review, including the last entry which links to the "go ahead"
> messages [3,4] from the folks whose comments were addressed in the
> last stage of the review. The original IRSG reviews are [5,6]
> and the RG "please ok" thread is [7].
>
> I'll be shepherd for this document which is intended to become
> an informational RFC.
>
> Regards,
> Stephen.
>
> [1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.txt
> [2] http://www1.tools.ietf.org/group/irtf/trac/ticket/6
> [3] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-December/ 
> 002456.html
> [4] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-January/ 
> 002486.html
> [5] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/ 
> 002173.html
> [6] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/ 
> 002173.html
> [7] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-February/ 
> 002091.html
>

Date: Thu, 11 Jan 2007 19:54:45 +0000
From: Stephen Farrell <[email-masked]>
To: Aaron Falk <[email-masked]>
CC: Internet Research Steering Group <[email-masked]>, DTN <[email-masked]>
Subject: [dtn-interest] DTNRG arch document ready to send to RFC editor
Sender: [email-masked]

Hi Aaron,

In accordance with current IRTF processes, the DTNRG arch
document [1], is now finished IRSG review and ready for you
to send to the RFC editor.

The tracker ticket [2] for this has links to the various stages of
the review, including the last entry which links to the "go ahead"
messages [3,4] from the folks whose comments were addressed in the
last stage of the review. The original IRSG reviews are [5,6]
and the RG "please ok" thread is [7].

I'll be shepherd for this document which is intended to become
an informational RFC.

Regards,
Stephen.

[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.txt
[2] http://www1.tools.ietf.org/group/irtf/trac/ticket/6
[3] 
http://mailman.dtnrg.org/pipermail/dtn-interest/2006-December/002456.html
[4] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-January/002486.html
[5] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/002173.html
[6] http://mailman.dtnrg.org/pipermail/dtn-interest/2006-May/002173.html
[7] 
http://mailman.dtnrg.org/pipermail/dtn-interest/2006-February/002091.html

Date: Wed, 10 Jan 2007 16:00:02 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] dtnrg not meeting in Prague...
Sender: [email-masked]

Hi Folks,

As agreed in San Diego, we plan not to have a dtnrg session at
the Prague IETF, so you probably should yell now if you do want
one,

Regards,
Stephen.

Content-class: urn:content-classes:message
Date: Tue, 9 Jan 2007 22:37:49 -0800
From: "Henderson, Thomas R" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Internet Steering Group" <[email-masked]>, <[email-masked]>, "Aaron Falk" <[email-masked]>
Subject: [dtn-interest] RE: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE JAN 9
Sender: [email-masked]

> 
> - Thomas Henderson had some problems with the EID term (and
> terminology in general). There were some editorial changes
> made, and it was pointed out that there is a terminology
> section in the bundle specification draft [3], (which will
> be starting its poll real soon now, btw).

Stephen,
I'm OK with this now, and I noticed the terminology section in the
bundle draft.  I think that the revision between -07 and -08 did help
the clarity.

I had just a few other nits on this version:

page 7:
The relative order of ADUs might not be preserved (add "by the
network").

page 8: 
s/life indicator/lifetime indicator/
s/and a length/and a length field/

page 13:
s/See Section 11/See Section 3.11/

page 15:
earlier it is stated that bundles have 2 or more blocks, but the third
sentence of section 3.7 implies that only the primary block is mandatory
(perhaps you mean that the primary block must be accompanied by at least
one payload or extension block, although either is optional)

Tom

Date: Fri, 05 Jan 2007 13:08:58 +0100
From: Luciana Pelusi <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [IEEE WoWMoM'07] CFP Autonomic and Opportunistic Communications (AOC),Workshop (Deadline: January 21, 2007)
Sender: [email-masked]

  We apologize in advance if you receive multiple copies of this CFP
********************************************************************

            *PRELIMINARY ANNOUNCEMENT AND CALL FOR PAPERS*

                     First IEEE WoWMoM Workshop on

    *** AUTONOMIC and OPPORTUNISTIC COMMUNICATIONS - AOC 2007 ***
                   June 18, 2007 - Helsinki, Finland
                     http://cnd.iit.cnr.it/aoc2007/

                             organized by
                       *ANA and HAGGLE projects*
              funded by the FET-IST Programme in the area
              Situated and Autonomic Communications (SAC)

               **** *Deadline --- January 21, 2007* ****

********************************************************************

We are faced with an era where the widespread use of small portable
wireless devices and wireless technologies are building the pervasive
vision. This pervaded world has generated new communication paradigms:
autonomic and opportunistic communications.
  Communication among devices in a pervasive environment can happen if
the devices can communicate autonomously, and manage their own evolution
and configuration changes in the network, without explicit user or
administrator action. In a pervasive world, even in the absence of any
connectivity infrastructure mobile devices can communicate using the
connection "opportunities" that arise due to mobility.
  The goal of this workshop is to provide a forum between the autonomic
and opportunistic communication communities to exchange ideas, discuss
solutions, and share experiences among researchers, professionals, and
application developers both from industry and academia. Original papers
addressing both theoretical and practical aspects of autonomic
communications and computing are solicited. Papers describing prototype
implementations and deployment are particularly welcome.

Topics of interest include but are not limited to:

Architecture and models for autonomic and opportunistic communications
Tools and techniques for designing, analyzing and building autonomic and
opportunistic networks
Adaptive security for self protection of networks
Economic, biological and social models used for autonomic and
opportunistic communications
Mobility models for opportunistic networking
Novel management techniques for autonomic and opportunistic communications
Sensing, monitoring and measurements for self-managing networks
Advanced technologies for enabling autonomic and opportunistic
communications
Autonomic and opportunistic communication testbeds and measurements

PAPER SUBMISSION AND PUBLICATION
=================================
Papers should neither have been published elsewhere nor currently
under review by another conference or journal.  Guidelines on paper
submission and formatting are available at http://cnd.iit.cnr.it/aoc2007/.
Accepted papers will appear in the symposium proceedings published by
IEEE. Extended versions of workshop selected papers will be considered
for possible fast track publication on the Pervasive and Mobile
Computing Journal (Elsevier).

IMPORTANT DATES
===============
Full papers due:        *January 21, 2007*
Notification:           March 1, 2007

ORGANIZING COMMITTEE
====================

WORKSHOP Chairs:
  Marco Conti, IIT-CNR, Italy
  Silvia Giordano, SUPSI, Switzerland
  Ioannis Stavrakakis, University of Athens, Greece

PUBLICITY Chair:
  Luciana Pelusi, IIT-CNR, Italy

PROGRAM COMMITTEE
  Giuseppe Anastasi, University of Pisa, Italy
  Stefano Basagni, Northeastern University, USA
  Edoardo Biagioni, University of Hawaii, USA
  Levente Buttyan, BUTE, Hungary
  Tracy Camp, Colorado School of Mines, USA
  Augustin Chaintreau, Thomson, France
  Ling-Jyh Chen, Academia Sinica, Taiwan
  Jon Crowcroft, University of Cambridge, UK
  Murat Demirbas, SUNY Buffalo, USA
  Spyros Denazis, Hitachi Europe, France & University of Patras, Greece
  Mohamed Eltoweissy, Virginia Tech., USA
  Mario Gerla, UCLA, USA
  Per Gunningberg, Uppsala University, Sweden
  Vincent Lenders, ETH, Switzerland
  Cecilia Mascolo, UCL, UK
  Martin May, ETH, Switzerland
  Daniele Miorandi, Create-net, Italy
  Refik Molva, Eurécom, France
  Konstantinos Oikonomou, Ionian University, Greece
  Joerg Ott, HUT, Finland
  Andrea Passarella, IIT-CNR, Italy
  Kaustubh Phanse, Uppsala University, Sweden
  George Polyzos, AUEB, Greece
  Chunming Qiao, SUNY Buffalo, USA
  Kave Salamandiam, EPFL, Switzerland
  Fabrizio Sestini, FET, European Commission
  Violet Syrotiuk, Arizona State University, USA
  John Vicente, Intel, USA
  Hongyi Wu, University of Louisiana, USA
  Laurence T. Yang, St Francis Xavier University, Canada
  Franco Zambonelli, University of Modena-Reggio, Italy
  Ellen W. Zegura, Georgia Tech, USA

-- 
---------------------------------------------------
Luciana Pelusi
     Ph.D. Student
     Pervasive Computing & Networking Lab. (PerLab)
     www.perlab.it

     Institute for Informatics and Telematics (IIT)
     Italian National Research Council (CNR)
     Via G. Moruzzi, 1 - 56124 Pisa, Italy

     phone: + 39 050 315 3059 (direct)
---------------------------------------------------

Date: Thu, 04 Jan 2007 10:29:22 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] CBHE internet draft submitted
Sender: [email-masked]

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

Since discussion of what I've been proposing as an initial CBHE draft 
seems to have reached a degree of tentative consensus, I have gone ahead 
and submitted the draft (as attached) to IETF, to be revisited in six 
months.

I've updated the ION implementation of BP to use the revised -- 
BPv5-compliant -- CBHE convention, and it seems to work okay.  In case 
it's helpful: I'm testing on an extremely small network (no more than 
127 "elements", no more than 127 "services", and scheme number is 1, so 
each EID SDNV is a single byte), sending bundles with 60000-byte 
payloads (the payload length SDNV is 3 bytes for payloads 16,384 to 
2,097,151 bytes in length), so I'm seeing primary block lengths of 20 
and payload block overhead of 5 bytes, for a total of 25 bytes of 
overhead per bundle, which is about .04% transmission overhead.  This 
will change to 26 bytes of total overhead per bundle along toward the 
end of June, 2008, when the creation time seconds SDNV in the primary 
block must increase from 4 bytes to 5 in order to contain the total 
number of seconds since January 1 of 2000.

Scott

--------------010207090309010402080806
Content-Type: text/plain;
 name="draft-burleigh-cbhe-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-burleigh-cbhe-00.txt"

Delay-Tolerant Networking Research Group                     S. Burleigh
Internet-Draft                                Jet Propulsion Laboratory,
Intended status: Experimental                   California Institute of
Expires: July 8, 2007                                         Technology
                                                         January 4, 2007

                Compressed Bundle Header Encoding (CBHE)
                         draft-burleigh-cbhe-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 8, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2007).

Abstract

   This document describes a convention for representing Delay-Tolerant
   Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a
   compressed manner within the primary blocks of bundles.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Burleigh                  Expires July 8, 2007                  [Page 1]

Internet-Draft                    CBHE                      January 2007

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Compression convention  . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Constraints . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Method  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.1.  Transmission  . . . . . . . . . . . . . . . . . . . . . . . 6
     3.2.  Reception . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8

Burleigh                  Expires July 8, 2007                  [Page 2]

Internet-Draft                    CBHE                      January 2007

1.  Introduction

   This document describes a convention for representing Delay-Tolerant
   Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a
   compressed manner within the primary blocks of bundles.

   Each DTN bundle's primary block contains four BP endpoint identifiers
   (EIDs), of which any two, any three, or even all four may be
   lexically identical: the endpoint identifiers of the source, the
   destination, the report-to endpoint, and the current custodian.  Each
   EID is a Uniform Record Identifier (URI), an ASCII string of the form
   "scheme_name:scheme_specific_part".

   A degree of block compression is provided by the design of the
   primary block: the scheme names and scheme-specific parts of the four
   endpoints' IDs - up to eight NULL-terminated strings - are
   concatenated at the end of the block in a variable-length character
   array called a "dictionary", enabling each EID to be represented by a
   pair of integers indicating the offsets (within the dictionary) of
   the EID's scheme name and scheme-specific part.  Duplicate strings
   may be omitted from the dictionary, so the actual number of
   concatenated NULL-terminated strings in the dictionary may be less
   than eight and two or more of the scheme name or scheme-specific part
   offsets in the block may have the same value.  Moreover, the eight
   offsets in the primary block are encoded as self-delimiting numeric
   values (SDNVs), which shrink to fit the encoded values; when the
   total length of the dictionary is less than 127 bytes, all eight
   offsets can be encoded into just eight bytes.

   However, these strategems do not prevent the scheme names and scheme-
   specific parts themselves from being arbitrarily lengthy strings of
   ASCII text.  It is therefore still possible for the length of a
   bundle's primary header to be a very large fraction of the total
   length of the bundle when the bundle's payload is relatively small,
   as is anticipated for a number of DTN applications such as space
   flight operations.

   The Compressed Bundle Header Encoding (CBHE) convention was developed
   to improve DTN transmission efficiency for such applications by
   further reducing the number of bytes used to express EIDs in the
   primary blocks of bundles.

2.  Compression convention

Burleigh                  Expires July 8, 2007                  [Page 3]

Internet-Draft                    CBHE                      January 2007

2.1.  Constraints

   Compressed Bundle Header Encoding (CBHE) is possible only when the
   scheme names of all non-null endpoint IDs in the primary block of a
   given bundle (that is, all endpoint IDs in the primary block that are
   not "dtn:none") identify a single scheme that is understood
   universally within the network to be "CBHE-conformant".

   All CBHE-conformant schemes are numbered and are identifiable by
   their numbers as well as their names.  A one-to-one correspondence
   between scheme numbers and the names of CBHE-conformant schemes is
   assumed to be well-known throughout the network (either by management
   or, as the scope of the network grows, by means of a protocol yet to
   be developed).

   The scheme-specific part of each entity-identifying URI whose scheme
   name identifies a CBHE-conformant scheme must be of the form
   "element_number.service_number".

   By convention, element number is a non-negative integer that can be
   thought of as a BP node identifier, such as a spacecraft identifier.
   Element number zero is used to indicate the null endpoint; any EID
   whose scheme name identifies a CBHE-conformant scheme and whose
   element number is zero, regardless of service number, is interpreted
   within the CBHE convention as an alternative representation of the
   standard null endpoint ID "dtn:none".

   By convention, service number is a non-negative integer that
   functions as a de-multiplexing token.  When the protocol encapsulated
   within BP has its own de-multiplexing identifiers, the service number
   may function in a manner similar to that of the protocol number in an
   IP packet, characterizing the bundle payload; alternatively, the
   service number may function in a manner similar to that of the port
   number in a UDP datagram.  Service numbers enable inbound bundles'
   application data units to be de-multiplexed to elements of
   application functionality that are designed to process them, so that
   effective communication relationships can be developed between bundle
   producers and consumers.

   Service number zero is used exclusively to identify BP custody signal
   traffic.

   Conversion of an EID in URI form - where the URI's scheme is CBHE-
   conformant - to and from a tuple of three integers is therefore
   straightforward.  This ease of conversion enables an array of
   integers to serve the same function as a dictionary of EID ASCII
   strings.

Burleigh                  Expires July 8, 2007                  [Page 4]

Internet-Draft                    CBHE                      January 2007

   To summarize, CBHE representation of EIDs in a given bundle's primary
   block is constrained as follows:

   o  The scheme names of all non-null endpoint IDs must be the same.

   o  The scheme name common to all non-null endpoint IDs must identify
      a scheme that is well-known to be CBHE-conformant, and that scheme
      must be uniquely identified by a well-known scheme number.

   o  The scheme-specific parts of all non-null endpoint IDs must be in
      "element_number.service_number" form, where both element_number
      and service_number are non-negative integers.

   o  If the bundle's Current Custodian endpoint ID is not null, then
      the service number for that endpoint ID must be zero.

2.2.  Method

   When the constraints summarized above are met, the CBHE block
   compression method can be applied.  In a CBHE-compressed primary
   block, the eight SDNVs that normally contain EIDs' offsets within the
   dictionary are instead used to contain the eight integer values
   listed below, in the order shown:

   1.  The scheme number that is common to all non-null endpoint IDs.

   2.  The element number of the destination endpoint ID, or zero if the
       destination endpoint is the null endpoint.

   3.  The service number of the destination endpoint ID, or zero if the
       destination endpoint is the null endpoint.

   4.  The element number of the source endpoint ID, or zero if the
       source endpoint is the null endpoint.

   5.  The service number of the source endpoint ID, or zero if the
       source endpoint is the null endpoint.

   6.  The element number of the report-to endpoint ID, or zero if the
       report-to endpoint is the null endpoint.

   7.  The service number of the report-to endpoint ID, or zero if the
       report-to endpoint is the null endpoint.

   8.  The element number of the current custodian endpoint ID, or zero
       if the current custodian endpoint is the null endpoint.

   Further, the dictionary is omitted from the primary block and the

Burleigh                  Expires July 8, 2007                  [Page 5]

Internet-Draft                    CBHE                      January 2007

   primary block's dictionary length is set to zero.

   This compression method is applied at the convergence layer: the
   transmitting convergence-layer adaptation compresses the primary
   block as shown above, and upon reception the receiving convergence-
   layer adaptation de-compresses the block by simply reversing the
   process.

3.  Specification

   CBHE compression is a convergence-layer adaptation.  It is opaque to
   bundle processing.  It therefore has no impact on the
   interoperability of different Bundle Protocol implementations, but
   instead affects only the interoperability of different convergence
   layer adaptation implementations.

   Bundle Protocol convergence-layer adapters that conform to the CBHE
   specification must implement the following procedures.

3.1.  Transmission

   When and only when required by the bundle protocol agent to transmit
   to some CBHE-conformant convergence-layer adapter a bundle whose
   primary block's endpoint IDs satisfy the constraints summarized in
   section 2.1 above and whose extension blocks (if any) contain no
   citations of endpoint IDs that are contained in the primary block's
   dictionary, the convergence layer adapter may encode the primary
   block of the bundle in accordance with the CBHE compression
   convention described in section 2.2 above.

3.2.  Reception

   Upon receiving a bundle whose dictionary length is zero (and only in
   this circumstance), the convergence layer adapter must decode the
   primary block of the bundle in accordance with the CBHE compression
   convention described in section 2.2 above before delivering it to the
   bundle protocol agent.

4.  IANA Considerations

   A new registry of CBHE-conformant URI schemes and corresponding
   scheme numbers may be needed.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

Burleigh                  Expires July 8, 2007                  [Page 6]

Internet-Draft                    CBHE                      January 2007

5.  Security Considerations

   CBHE introduces no new security considerations beyond those discussed
   in the DTN Bundle Protocol and Bundle Security Protocol
   specifications.

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Author's Address

   Scott Burleigh
   Jet Propulsion Laboratory, California Institute of Technology
   4800 Oak Grove Drive, m/s 301-490
   Pasadena, CA  91109
   USA

Burleigh                  Expires July 8, 2007                  [Page 7]

Internet-Draft                    CBHE                      January 2007

Full Copyright Statement

   Copyright (C) The Internet Society (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Burleigh                  Expires July 8, 2007                  [Page 8]


--------------010207090309010402080806--

Date: Tue, 2 Jan 2007 08:30:28 +0530
From: "Deepak Nadig" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Network Simulator Module for DTNs
Sender: [email-masked]

Hi all,

This is regarding the availability of an ns-2 module for DTNs.
The module available at http://www.illuvatar.nu/ns-dtn/ does not work
with dynamic routing scenarios. Is there anyone working on an ns-2
module that implements this feature?

Thanks
Deepak