Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...
From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 30 Jul 2010 08:03:44 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, July 30, 2010 7:19 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to
> go...
> 
> Figs 3 and 4 give layout specifications that do not imply SDNV processing
> (there's no eighth bit, while a processed SDNV value uses all bits,
> indicating that these are the output fields, not SDNV content post
> processing). I would give the figures precedence over any contradicting
> text.

Lloyd, the first paragraph of section 4.2 -- a detailed characterization of Figure 3 -- is what we would term "explanatory" text that is consistent with the way Figure 3 is meant to be understood, rather than "contradicting" text that is in conflict with the way Figure 3 is meant to be understood.  We guessed that the former would be more helpful than the latter to people reading the RFC; since several interoperable implementations of Bundle Protocol have been developed and demonstrated, this strategy seems to have been generally successful.  You are, of course, free to misinterpret Figure 3 in any way you like.

Scott

Date: Fri, 30 Jul 2010 10:57:20 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries	ready	to	go...

On 7/30/10 10:18 AM, [email-masked] wrote:
> Figs 3 and 4 give layout specifications that do not imply SDNV processing (there's no eighth bit, while a processed SDNV value uses all bits, indicating that these are the output fields, not SDNV content post processing). I would give the figures precedence over any contradicting text.

That's not the way that RFCs are meant to be read; the 
figures are illustrations and the text is definitive.

Here's what the text of section 4.2 says:

"The bundle processing control flags field in the primary 
bundle block of each bundle is an SDNV; the value encoded in 
this SDNV is a string of bits used to invoke selected bundle 
processing control features.  The significance of the value 
in each currently defined position of this bit string is 
described here.  Note that in the figure and descriptions, 
the bit label numbers denote position (from least 
significant ('0') to most significant) within the decoded 
bit string, and not within the representation of the bits on 
the wire. ..."

If you don't think it should be SDNV, that's another discussion.

-Dan

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Simon Perreault <[email-masked]>
Date: Fri, 30 Jul 2010 07:43:35 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to	go...

> -----Original Message-----
> From: Simon Perreault [mailto:[email-masked]]
> Sent: Friday, July 30, 2010 12:24 AM
> To: Burleigh, Scott C (313B)
> Cc: [email-masked]; Marc Blanchet
> Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to
> go...
> 
> Burleigh, Scott C (313B) wrote, on 07/29/2010 10:24 PM:
> >> - In section 2.3, since this is an SDNV, and RFC 5050 says that
> >> implementations
> >> may ignore SDNVs larger than 2^64, could we say that the range is "0 to
> 63"
> >> instead of "variable"? Then list 21-63 as Unassigned. This would better
> >> reflect
> >> the actual, practical range.
> >
> > I think the reasoning here is right but I disagree with the arithmetic.
> The value range is indeed constrained by RFC 5050, but I figure that means
> the range is "0 to (2^64 -1)" -- or maybe we'd say it as "64-bit integer" -
> - rather than "0 to 63".
> >
> > Bit positions 21-63 are unassigned, but the range of unassigned *values*
> is much larger.
> 
> The column's header is "Bit position (right to left)" and I don't know how we
> can have a bit position > 63 for a 64-bit value.
> 
> This registry is registering single bits out of the 64 that are available, not
> values made out of several bits.

Sure, but I wasn't talking about the column header or the contents of that column.  When I said the value range should be written as "0 to (2^64 - 1)" or as "64-bit integer" [and Lloyd is quite correct, I should have said "unsigned 64-bit integer"] I was talking about the text to write next to the words "The value range is:" and trying to be consistent with the corresponding text in 2.1 and 2.2.

I agree that we can't have a bit position > 63 for a 64-bit value.  But a bit position is not a value.  The bundle processing control flags field is an SDNV, an unsigned integer of self-declared length.  That number has a value, just as an unsigned integer of externally declared length has a value: the halfword 0x000b has the value 11 (decimal), for example, and the single-byte SDNV 00001011 has the same value.  Certainly we can't talk about the significance of bit 13 of a single-byte SDNV containing only 7 significant bits.  But the range of values for this SDNV is 0-127, not 0-6.

Scott

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Fri, 30 Jul 2010 15:18:52 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries	ready	to	go...

Figs 3 and 4 give layout specifications that do not imply SDNV processing (there's no eighth bit, while a processed SDNV value uses all bits, indicating that these are the output fields, not SDNV content post processing). I would give the figures precedence over any contradicting text.

There is no reason for interoperability for the flags field to be treated within an implementation as SDNV, and good performance reasons not to do so.

(This is all a bit moot, so I'll stop here. Sensible DTN implementations likely aren't using bundling at all!)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Ellard
Sent: 30 July 2010 14:30
To: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...

On 7/30/10 8:18 AM, [email-masked] wrote:
> Well, DTN2 has never really concerned itself with performance.

Reiterating what Simon wrote...  Whether or not it is the most efficient way to accomplish the goal, 5050 says that it's SDNV, and therefore all sensible (by which I mean 'conformant', although opinions may differ about whether sensibility implies conformance) implementations should treat this field as SDNV.

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

Date: Fri, 30 Jul 2010 14:31:05 +0100
From: Elwyn Davies <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] DTN2 Functional Specification available

ANNOUNCEMENT

As part of N4C Avri Doria and I have reverse emgineered the functional 
specification of DTN2, including a detailed specification of the API and 
full documentation of the TCL command interface.

It is almost 200 pages long!

It isnot quite complete because N4C does not currently need the Session 
part and the external router and convergence layer interface.

It can be found at 
http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf

Coments gratefully received

I intend to  try and add the command interface stuff into the DTN2 
manual pages.

Regards,
Elwyn

Date: Fri, 30 Jul 2010 09:30:07 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries	ready	to	go...

On 7/30/10 8:18 AM, [email-masked] wrote:
> Well, DTN2 has never really concerned itself with performance.

Reiterating what Simon wrote...  Whether or not it is the 
most efficient way to accomplish the goal, 5050 says that 
it's SDNV, and therefore all sensible (by which I mean 
'conformant', although opinions may differ about whether 
sensibility implies conformance) implementations should 
treat this field as SDNV.

-Dan

From: <[email-masked]>
To: <[email-masked]>
Date: Fri, 30 Jul 2010 13:18:00 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready	to	go...

Well, DTN2 has never really concerned itself with performance.

(With the coming-from-Berkeley dependencies on Tcl and BerkeleyDB,
the C++ vector stuff, etc, 'ridiculous amount of programming'
summarizes the DTN2 accomplishment nicely. Impressive, but not
something you'd want to run in constrained real environments
such as in space. We're just lucky Mike Demmer wasn't at MIT,
otherwise there'd be a half a Lisp machine in there instead
of the Berkeley heritage, and config would be so much more fun...)

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: 30 July 2010 12:34
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...
Importance: High

[email-masked] wrote, on 07/30/2010 12:03 PM:
> Sensible
> implementations won't go 'oh, let's grab this SDNV, then turn it back 
> into a flag field after processing and shifting all the bits, then 
> figure out the bit positions retroactively' as that's just a 
> ridiculous amount of programming

That's exactly what DTN 2 does.

My point is that with the way it's phrased in RFC 5050, we can't expect implementations not to limit themselves to 64 bits.

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 30 Jul 2010 07:07:44 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTN Network Management draft

06 Jun 2009  	draft-ivancic-dtnrg-network-management-reqs

I have no plans to move this forward at this time.

- Will

Date: Fri, 30 Jul 2010 13:34:01 +0200
From: Simon Perreault <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready	to	go...

[email-masked] wrote, on 07/30/2010 12:03 PM:
> Sensible
> implementations won't go 'oh, let's grab this SDNV, then turn it back
> into a flag field after processing and shifting all the bits, then
> figure out the bit positions retroactively' as that's just a ridiculous
> amount of programming

That's exactly what DTN 2 does.

My point is that with the way it's phrased in RFC 5050, we can't expect
implementations not to limit themselves to 64 bits.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

Date: Fri, 30 Jul 2010 11:23:31 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] IETF-78 meeting materials...

...are at. [1]

If you're remote and listening, then do let us know in the jabber
room ([email-masked] room).

Stephen.

[1] https://datatracker.ietf.org/meeting/78/materials.html#wg-DTNRG

From: <[email-masked]>
To: <[email-masked]>
Date: Fri, 30 Jul 2010 11:03:34 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready	to	go...

RFC5050 says:

   Implementations of the bundle protocol may handle as an invalid
   numeric value any SDNV that encodes an integer that is larger than
   (2^64 - 1).

That's not a must - and when considering the individual bit values for
flags, the actual SDNV value does not have to be computed. Sensible
implementations won't go 'oh, let's grab this SDNV, then turn it back
into a flag field after processing and shifting all the bits, then
figure out the bit positions retroactively' as that's just a ridiculous
amount of programming -- they'll say 'this is expected to be a flag field,
let's go evaluate 7 bits in each byte after grabbing each byte directly.'
(And figure 3 supports this view by being 7-bit delineated, rather
than working on the 8-bit boundaries you'd have once the SDNV
value has been computed.)

In other words, the limit on SDNV values only applies once an attempt
has been made to compute the SDNV value. When the SDNV value is
meaningless and the field is being used as a placeholder to encode
flags with a bit per byte of overhead rather than an integer, the above
quoted text doesn't apply - the numeric value isn't meaningful,
isn't computed, and isn't an issue.

   An SDNV can be used to represent both very large and very small
   integer values.

No, that's -unsigned integer- values (saying 'natural numbers' is
ambiguous at to zero). Good luck with representing -1.

(2^64-1 is not 'very large'. It's less than Avogadro's number,
which we all encountered in grade school...)

Lloyd Wood
http://sat-net.com/L.Wood/dtn

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: 30 July 2010 10:36
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...
Importance: High

[email-masked] wrote, on 07/30/2010 11:24 AM:
> If an SDNV field is being treated as a flag field, it can be as long 
> as you want provided the last 'end of SDNV' bit is not set. ie there 
> are 7 flag bits in every SDNV-field-repurposed-as-flag-field, which is 
> arguably increasingly inefficient compared to the SDNV values you 
> could use instead -- but a lot easier to process, less error-prone...

I agree with you in principle, but that's not what RFC 5050 says.
Implementations are allowed to drop SDNVs longer than 64 bits. There nothing to the effect that "SDNVs containing bit strings may be longer", or "there may be more than 64 bundle processing control flags".

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

Date: Fri, 30 Jul 2010 11:35:58 +0200
From: Simon Perreault <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready	to	go...

[email-masked] wrote, on 07/30/2010 11:24 AM:
> If an SDNV field is being treated as a flag field, it can be as long as you
> want provided the last 'end of SDNV' bit is not set. ie there are 7 flag bits
> in every SDNV-field-repurposed-as-flag-field, which is arguably increasingly
> inefficient compared to the SDNV values you could use instead -- but a lot
> easier to process, less error-prone...

I agree with you in principle, but that's not what RFC 5050 says.
Implementations are allowed to drop SDNVs longer than 64 bits. There nothing to
the effect that "SDNVs containing bit strings may be longer", or "there may be
more than 64 bundle processing control flags".

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

From: <[email-masked]>
To: <[email-masked]>
Date: Fri, 30 Jul 2010 10:24:54 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready	to	go...

Sorry, that doesn't make any sense.

If an SDNV field is being treated as a flag field, it can be as long as you want provided the last 'end of SDNV' bit is not set. ie there are 7 flag bits in every SDNV-field-repurposed-as-flag-field, which is arguably increasingly inefficient compared to the SDNV values you could use instead -- but a lot easier to process, less error-prone...

Talking about SDNV ranges and values, and how they are assigned, makes more sense than talking about bits in this context.

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: 30 July 2010 10:16
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...
Importance: High

[email-masked] wrote, on 07/30/2010 11:10 AM:
> If it's registering single bits as flags, how can it be an SDNV?

RFC 5050 specifies that implementations are not required to handle SDNVs higher than 2^64-1. Therefore the maximum, practical range is 64 bits.

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

Date: Fri, 30 Jul 2010 11:16:17 +0200
From: Simon Perreault <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready	to	go...

[email-masked] wrote, on 07/30/2010 11:10 AM:
> If it's registering single bits as flags, how can it be an SDNV?

RFC 5050 specifies that implementations are not required to handle SDNVs higher
than 2^64-1. Therefore the maximum, practical range is 64 bits.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Fri, 30 Jul 2010 10:10:53 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready	to	go...

Scott: 64-bit UNSIGNED integer, surely? 

If it's registering single bits as flags, how can it be an SDNV?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: 30 July 2010 08:24
To: Burleigh, Scott C (313B)
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...

Burleigh, Scott C (313B) wrote, on 07/29/2010 10:24 PM:
>> - In section 2.3, since this is an SDNV, and RFC 5050 says that 
>> implementations may ignore SDNVs larger than 2^64, could we say that 
>> the range is "0 to 63"
>> instead of "variable"? Then list 21-63 as Unassigned. This would 
>> better reflect the actual, practical range.
> 
> I think the reasoning here is right but I disagree with the arithmetic.  The value range is indeed constrained by RFC 5050, but I figure that means the range is "0 to (2^64 -1)" -- or maybe we'd say it as "64-bit integer" -- rather than "0 to 63".
> 
> Bit positions 21-63 are unassigned, but the range of unassigned *values* is much larger.

The column's header is "Bit position (right to left)" and I don't know how we can have a bit position > 63 for a 64-bit value.

This registry is registering single bits out of the 64 that are available, not values made out of several bits.

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

Date: Fri, 30 Jul 2010 09:24:27 +0200
From: Simon Perreault <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to	go...

Burleigh, Scott C (313B) wrote, on 07/29/2010 10:24 PM:
>> - In section 2.3, since this is an SDNV, and RFC 5050 says that
>> implementations
>> may ignore SDNVs larger than 2^64, could we say that the range is "0 to 63"
>> instead of "variable"? Then list 21-63 as Unassigned. This would better
>> reflect
>> the actual, practical range.
> 
> I think the reasoning here is right but I disagree with the arithmetic.  The value range is indeed constrained by RFC 5050, but I figure that means the range is "0 to (2^64 -1)" -- or maybe we'd say it as "64-bit integer" -- rather than "0 to 63".
> 
> Bit positions 21-63 are unassigned, but the range of unassigned *values* is much larger.

The column's header is "Bit position (right to left)" and I don't know how we
can have a bit position > 63 for a 64-bit value.

This registry is registering single bits out of the 64 that are available, not
values made out of several bits.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

From: Darren Long <[email-masked]>
Date: Thu, 29 Jul 2010 23:41:02 +0100
To: "Oyake, Amalaye (316D)" <[email-masked]>
Cc: DTN Interest <[email-masked]>
Subject: Re: [dtn-interest] AX.25 / Packet radio convergence layer ...?

--Boundary_(ID_NkJIoiB9PHjQGUJq1nzAQw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Amalaye,

Do you mean that ION will have an AX.25 Convergence Layer too?

Darren

On 29 Jul 2010, at 23:34, Oyake, Amalaye (316D) wrote:

> Hello,
> 
> I am currently looking into this. The work will be done against ION. I do not have too much to add.
> 
> Regards,
> 
> * Amalaye Oyake                                    *
> * Flight Software Applications & Data Product Mgmt */\
> * 818.393.7168 work   626.399.1707 cell            *||
> * Jet Propulsion Laboratory, Pasadena  CA 91109   */||\
> -- 
> 
> 
> 
> 
> On Thursday07/29/2010 Thursday~07/29/2010 -9:36 AM, "Jordan Hayes" <[email-masked]> wrote:
> 
> Has anyone looked into this?
> 
> /jordan
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Boundary_(ID_NkJIoiB9PHjQGUJq1nzAQw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi&nbsp;<span class="Apple-style-span" style="font-family: Inconsolata; font-size: 16px; ">Amalaye,</span><div><font class="Apple-style-span" face="Inconsolata"><br></font></div><div><font class="Apple-style-span" face="Inconsolata">Do you mean that ION will have an AX.25 Convergence Layer too?</font></div><div><font class="Apple-style-span" face="Inconsolata"><br></font></div><div><font class="Apple-style-span" face="Inconsolata">Darren</font></div><div><font class="Apple-style-span" face="Inconsolata"><br></font><div><div>On 29 Jul 2010, at 23:34, Oyake, Amalaye (316D) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>
<font face="Inconsolata"><span style="font-size:12pt">Hello,<br>
<br>
I am currently looking into this. The work will be done against ION. I do not have too much to add.<br>
<br>
Regards,<br>
<br>
* Amalaye Oyake &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*<br>
* Flight Software Applications &amp; Data Product Mgmt */\<br>
* 818.393.7168 work &nbsp;&nbsp;626.399.1707 cell &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*||<br>
* Jet Propulsion Laboratory, Pasadena &nbsp;CA 91109 &nbsp;&nbsp;*/||\<br>
-- <br>
<br>
<br>
<br>
<br>
On Thursday07/29/2010 Thursday~07/29/2010 -9:36 AM, "Jordan Hayes" &lt;<a href="x-msg://402/[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
</span></font><blockquote><font face="Inconsolata"><span style="font-size:12pt">Has anyone looked into this?<br>
<br>
/jordan<br>
_______________________________________________<br>
dtn-interest mailing list<br>
<a href="x-msg://402/[email-masked]">[email-masked]</a><br>
<a href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>
<br>
</span></font></blockquote>
</div>

_______________________________________________<br>dtn-interest mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br><a href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br></blockquote></div><br></div></body></html>

--Boundary_(ID_NkJIoiB9PHjQGUJq1nzAQw)--

From: "Oyake, Amalaye (316D)" <[email-masked]>
To: Jordan Hayes <[email-masked]>, DTN Interest <[email-masked]>
Date: Thu, 29 Jul 2010 15:34:27 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] AX.25 / Packet radio convergence layer ...?

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

Hello,

I am currently looking into this. The work will be done against ION. I do n=
ot have too much to add.

Regards,

* Amalaye Oyake                                    *
* Flight Software Applications & Data Product Mgmt */\
* 818.393.7168 work   626.399.1707 cell            *||
* Jet Propulsion Laboratory, Pasadena  CA 91109   */||\
--

On Thursday07/29/2010 Thursday~07/29/2010 -9:36 AM, "Jordan Hayes" <jordan@=
bitway.com> wrote:

Has anyone looked into this?

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

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

<HTML>
<HEAD>
<TITLE>Re: [dtn-interest] AX.25 / Packet radio convergence layer ...?</TITL=
E>
</HEAD>
<BODY>
<FONT FACE=3D"Inconsolata"><SPAN STYLE=3D'font-size:12pt'>Hello,<BR>
<BR>
I am currently looking into this. The work will be done against ION. I do n=
ot have too much to add.<BR>
<BR>
Regards,<BR>
<BR>
* Amalaye Oyake &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;*<BR>
* Flight Software Applications &amp; Data Product Mgmt */\<BR>
* 818.393.7168 work &nbsp;&nbsp;626.399.1707 cell &nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*||<BR>
* Jet Propulsion Laboratory, Pasadena &nbsp;CA 91109 &nbsp;&nbsp;*/||\<BR>
-- <BR>
<BR>
<BR>
<BR>
<BR>
On Thursday07/29/2010 Thursday~07/29/2010 -9:36 AM, &quot;Jordan Hayes&quot=
; &lt;<a href=3D"[email-masked]">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Inconsolata"><SPAN STYLE=3D'font-si=
ze:12pt'>Has anyone looked into this?<BR>
<BR>
/jordan<BR>
_______________________________________________<BR>
dtn-interest mailing list<BR>
<a href=3D"[email-masked]">dtn-interest@maillist=
s.intel-research.net</a><BR>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><BR=
>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--_000_C8775003CD54AmalayeOyakejplnasagov_--

Date: Thu, 29 Jul 2010 15:01:26 -0700 (PDT)
From: Lyndon Nerenberg <[email-masked]>
To: Warren Kumari <[email-masked]>
Organization: The Frobozz Magic Homing Pigeon Company
Cc: DTN Interest <[email-masked]>
Subject: Re: [dtn-interest] AX.25 / Packet radio convergence layer ...?

> If in the Northern Virginia, US area we could try get this going over a 
> longer distance

I would be interested in conducting tests over HF.

From: Darren Long <[email-masked]>
Date: Thu, 29 Jul 2010 23:00:36 +0100
To: Warren Kumari <[email-masked]>
Cc: DTN Interest <[email-masked]>
Subject: Re: [dtn-interest] AX.25 / Packet radio convergence layer ...?

If either of you (or anyone else, for that matter) does do any testing of the AX.25 Connected Mode CL, I'd really appreciate feedback, of any kind.

Cheers,

Darren, G0HWW

On 29 Jul 2010, at 22:54, Warren Kumari wrote:

> Where are you located?
> 
> If in the Northern Virginia, US area we could try get this going over a longer distance
> 
> Warren Kumari (AC4WK)
> ------
> Please excuse typing, etc -- This was sent from a device with a tiny keyboard.
> 
> On Jul 29, 2010, at 11:29 PM, Darren Long <[email-masked]> wrote:
> 
>> Hi Jordan,
>> 
>> The AX.25 CL is my baby/fault :)
>> 
>> There is a Howto at http://www.dtnrg.org/wiki/AX25ConnectedModeConvergenceLayer
>> 
>> I've been using it over the last couple of weeks on a UHF (70cm) link (in my house).  I've been testing a mechanism to reduce the number of CL ack segments but still 
>> support a low enough granularity to ensure that reactive fragmentation is useful.
>> 
>> I've been sending bundles of about 60kB (need plenty of patience for bigger payloads) with a maxframe of 1.
>> 
>> John Ronan (EI7IG) is somewhat better equipped than I and has done some more extensive testing in the past, and will (I hope) resume testing soon.
>> 
>> It may be better to continue any further discussion on the dtn-users list.
>> 
>> Cheers,
>> 
>> Darren Long, G0HWW
>> 
>> 
>> On 29 Jul 2010, at 17:36, Jordan Hayes wrote:
>> 
>>> Has anyone looked into this?
>>> 
>>> /jordan
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Jul 2010 23:54:54 +0200
To: Darren Long <[email-masked]>
Cc: DTN Interest <[email-masked]>
Subject: Re: [dtn-interest] AX.25 / Packet radio convergence layer ...?

Where are you located?

If in the Northern Virginia, US area we could try get this going over a longer distance

Warren Kumari (AC4WK)
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

On Jul 29, 2010, at 11:29 PM, Darren Long <[email-masked]> wrote:

> Hi Jordan,
> 
> The AX.25 CL is my baby/fault :)
> 
> There is a Howto at http://www.dtnrg.org/wiki/AX25ConnectedModeConvergenceLayer
> 
> I've been using it over the last couple of weeks on a UHF (70cm) link (in my house).  I've been testing a mechanism to reduce the number of CL ack segments but still 
> support a low enough granularity to ensure that reactive fragmentation is useful.
> 
> I've been sending bundles of about 60kB (need plenty of patience for bigger payloads) with a maxframe of 1.
> 
> John Ronan (EI7IG) is somewhat better equipped than I and has done some more extensive testing in the past, and will (I hope) resume testing soon.
> 
> It may be better to continue any further discussion on the dtn-users list.
> 
> Cheers,
> 
> Darren Long, G0HWW
> 
> 
> On 29 Jul 2010, at 17:36, Jordan Hayes wrote:
> 
>> Has anyone looked into this?
>> 
>> /jordan
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Darren Long <[email-masked]>
Date: Thu, 29 Jul 2010 22:29:40 +0100
To: Jordan Hayes <[email-masked]>
Cc: DTN Interest <[email-masked]>
Subject: Re: [dtn-interest] AX.25 / Packet radio convergence layer ...?

Hi Jordan,

The AX.25 CL is my baby/fault :)

There is a Howto at http://www.dtnrg.org/wiki/AX25ConnectedModeConvergenceLayer

I've been using it over the last couple of weeks on a UHF (70cm) link (in my house).  I've been testing a mechanism to reduce the number of CL ack segments but still 
support a low enough granularity to ensure that reactive fragmentation is useful.

I've been sending bundles of about 60kB (need plenty of patience for bigger payloads) with a maxframe of 1.

John Ronan (EI7IG) is somewhat better equipped than I and has done some more extensive testing in the past, and will (I hope) resume testing soon.

It may be better to continue any further discussion on the dtn-users list.

Cheers,

Darren Long, G0HWW

On 29 Jul 2010, at 17:36, Jordan Hayes wrote:

> Has anyone looked into this?
> 
> /jordan
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Thu, 29 Jul 2010 13:35:45 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Document status check

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, July 29, 2010 8:00 AM
> To: DTN
> Subject: [dtn-interest] Document status check
> 
> 
> Hi all,
> 
> As usual, there're a bunch of I-Ds with dtnrg in their
> name, so I'd just like to get a sense of the state-of-play
> for these. Feel free to reply to the list, or just Kevin
> and I. The full list is at [1], but the list that I think
> is relevant is below, though I may have missed something,
> esp. if the file name is odd (note that the list omits
> the drafts that are already progressing).
> 
> What I'd like is to get is a sense of whether you think
> drafts are dead or not, and if not, roughly where you think
> your draft is going, (and when).
> 
> If you think the draft should live, but no longer have
> cycles to work on it, then that's interesting too - we
> may be able to recruit some new authors.
> 
> I can start the ball rolling: I think of draft-farrell-dtnrg-km
> as a reminder that we've not done much in the way of key
> mgmt and should, but the draft wasn't ever really aimed
> at being an RFC. If someone wanted to revive or replace that,
> that'd be fine by me.
> 
> Thanks,
> Stephen.
> 
> [1] http://tools.ietf.org/id/dtnrg
> 
> DTNRG non-expired:
> 
> 01 Jun 2010  	draft-irtf-dtnrg-ecos

The ECOS draft is still active, and I'd like to get it into the review mill soon.

> DTNRG expired:
> 
> 31 Mar 2009  	draft-irtf-dtnrg-dtn-uri-scheme

I thought this one had gotten resubmitted.  It's still alive, as far as I know, but not at the top of anybody's priority list.

> PERS non-expired:
> 
> 09 Jul 2010  	draft-burleigh-dtnrg-cgr

Still active.  There's a bit of research going on here, so the draft isn't yet sufficiently baked to start the review cycle.

> 10 Feb 2010  	draft-burleigh-dtnrg-ltpcl

Still alive, and not changing much at this point.  Might be mature enough to start reviewing.

Scott

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Simon Perreault <[email-masked]>, "[email-masked]" <[email-masked]>, Marc Blanchet <[email-masked]>
Date: Thu, 29 Jul 2010 13:24:15 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to	go...

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Simon Perreault
> Sent: Thursday, July 29, 2010 6:42 AM
> To: [email-masked]; Marc Blanchet
> Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to
> go...
> 
> Stephen Farrell wrote, on 07/29/2010 02:59 PM:
> > Please read and comment in the next month (giving longer for
> > vacations), since this the other documents will (at some stage)
> > block on this.
> 
> I just read it. Some comments:
> 
> - The document cites the Licklider RFC but does not define any registry
> related
> to it. Is this intentional? I find it at least a bit confusing.
> 
> - At <http://www.dtnrg.org/wiki/AssignedNamesAndNumbers> there is a
> registry
> named "Cipher Suites used in the Bundle Security Protocols". Can we expect
> a
> later revision of draft-irtf-dtnrg-bundle-security to contain this registry
> in
> its IANA Considerations section, or should this draft include it? I think
> the
> former would be preferable.
> 
> - In section 2.3, since this is an SDNV, and RFC 5050 says that
> implementations
> may ignore SDNVs larger than 2^64, could we say that the range is "0 to 63"
> instead of "variable"? Then list 21-63 as Unassigned. This would better
> reflect
> the actual, practical range.

I think the reasoning here is right but I disagree with the arithmetic.  The value range is indeed constrained by RFC 5050, but I figure that means the range is "0 to (2^64 -1)" -- or maybe we'd say it as "64-bit integer" -- rather than "0 to 63".

Bit positions 21-63 are unassigned, but the range of unassigned *values* is much larger.

> - Same comment for 2.4. Suggestion: range should be "0 to 63" and 7-63
> should be
> listed as Unassigned.
> 
> 
> Minor/editorial:
> 
> - In section 2.5, can we make the left column have the same format as in
> sections 2.3 and 2.4? That is, instead of listing binary values, list bit
> position.

I agree that this would be more consistent.

These details aside, I agree that the document should be progressed.

Scott

Date: Thu, 29 Jul 2010 12:31:02 -0700
From: "Bradley D. Thornton" <[email-masked]>
Organization: NorthTech Computer
To: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to	go...

I too, will side w/Peter on this, that it is, "Good to go."

On 7/29/2010 6:27 AM, Peter Lovell wrote:
> On Thu, Jul 29, 2010, Stephen Farrell <[email-masked]> wrote:
> 
>>
>> This document [1] creates and populates IANA registries for the BP
>> that are needed by some of the I-Ds we're trying to turn into RFCs
>> now.
>>
>> I think its ready to go to the IRSG for review.
>>
>> Please read and comment in the next month (giving longer for
>> vacations), since this the other documents will (at some stage)
>> block on this.
>>
>> Deadline for comments is end of August.
>>
>> A couple of messages saying "this is good to go" would be
>> useful.
>>
>> If there are minor editorial comments we can process those as
>> we go, so do send those as well, but in that case, please be
>> clear as to whether or not you think this should be progressed
>> now regardless of your editorial comments.
>>
>> Thanks,
>> Stephen.
> 
> Hi Stephen,
> 
> I looked through this when I was adding similar things to BSP draft.
> 
> I vote that "this is good to go"
> 
> Cheers.....Peter
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

- -- 
Bradley D. Thornton
Manager Network Services
NorthTech Computer
TEL: +1.760.666.2703  (US)
TEL: +44.702.405.1909 (UK)
http://NorthTech.US

From: Hans Kruse <[email-masked]>
To: Joerg Ott <[email-masked]>
Date: Thu, 29 Jul 2010 14:20:22 -0400
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Document status check

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

Cool.  I'll take the lead for the udpcl one then, and provide edits  
for tcpcl to you.

On Jul 29, 2010, at 12:35 PM, Joerg Ott wrote:

> Hi,
>
> I had an update to tcpcl on my list, but it just did not
> make this.  This doc is mostly done.  We raised some
> implementation issues at some point, but nothing conclusive
> resulted from the discussion.  So, we may as well go ahead.
>
> Joerg
>
> Stephen Farrell wrote:
>> Hi all,
>>
>> As usual, there're a bunch of I-Ds with dtnrg in their
>> name, so I'd just like to get a sense of the state-of-play
>> for these. Feel free to reply to the list, or just Kevin
>> and I. The full list is at [1], but the list that I think
>> is relevant is below, though I may have missed something,
>> esp. if the file name is odd (note that the list omits
>> the drafts that are already progressing).
>>
>> What I'd like is to get is a sense of whether you think
>> drafts are dead or not, and if not, roughly where you think
>> your draft is going, (and when).
>>
>> If you think the draft should live, but no longer have
>> cycles to work on it, then that's interesting too - we
>> may be able to recruit some new authors.
>>
>> I can start the ball rolling: I think of draft-farrell-dtnrg-km
>> as a reminder that we've not done much in the way of key
>> mgmt and should, but the draft wasn't ever really aimed
>> at being an RFC. If someone wanted to revive or replace that,
>> that'd be fine by me.
>>
>> Thanks,
>> Stephen.
>>
>> [1] http://tools.ietf.org/id/dtnrg
>>
>> DTNRG non-expired:
>>
>> 28 Apr 2010  	draft-irtf-dtnrg-bundle-age-block
>> 01 Jun 2010  	draft-irtf-dtnrg-ecos	
>> 17 May 2010  	draft-irtf-dtnrg-bundle-previous-hop-block
>> 08 May 2010  	draft-irtf-dtnrg-bundle-checksum
>> 08 Mar 2010  	draft-irtf-dtnrg-ipnd	
>>
>> DTNRG expired:
>>
>> 05 Oct 2009  	draft-irtf-dtnrg-bundle-retrans-block
>> 12 Aug 2009  	draft-irtf-dtnrg-bundle-divert	
>> 12 Aug 2009  	draft-irtf-dtnrg-bundle-encapsulation	
>> 31 Mar 2009  	draft-irtf-dtnrg-dtn-uri-scheme	
>> 09 Mar 2009  	draft-irtf-dtnrg-sec-overview
>> 19 Nov 2008  	draft-irtf-dtnrg-udp-clayer
>> 03 Nov 2008  	draft-irtf-dtnrg-tcp-clayer	
>>
>> PERS non-expired:
>>
>> 09 Jul 2010  	draft-burleigh-dtnrg-cgr
>> 08 May 2010  	draft-wood-dtnrg-saratoga
>> 08 May 2010  	draft-wood-dtnrg-http-dtn-delivery
>> 28 Feb 2010  	draft-fall-dtnrg-schl
>> 27 Feb 2010  	draft-mcmahon-dtnrg-dtn-edp
>> 10 Feb 2010  	draft-burleigh-dtnrg-ltpcl
>> 09 Feb 2010  	draft-irtf-dtnrg-ding-network-management
>>
>> PERS expired:
>>
>> 26 Oct 2009  	draft-davies-dtnrg-uri-find
>> 12 Aug 2009  	draft-symington-dtnrg-bundle-multicast-custodial
>> 06 Jun 2009  	draft-ivancic-dtnrg-network-management-reqs
>> 22 May 2009  	draft-pbasu-dtnrg-naming
>> 19 Jun 2007  	draft-farrell-dtnrg-km
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

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

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Cool. &nbsp;I'll take the lead =
for the udpcl one then, and provide edits for tcpcl to =
you.<div><br><div><div>On Jul 29, 2010, at 12:35 PM, Joerg Ott =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Hi,<br><br>I had an update to tcpcl on my list, but =
it just did not<br>make this. &nbsp;This doc is mostly done. &nbsp;We =
raised some<br>implementation issues at some point, but nothing =
conclusive<br>resulted from the discussion. &nbsp;So, we may as well go =
ahead.<br><br>Joerg<br><br>Stephen Farrell wrote:<br><blockquote =
type=3D"cite">Hi all,<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">As usual, =
there're a bunch of I-Ds with dtnrg in their<br></blockquote><blockquote =
type=3D"cite">name, so I'd just like to get a sense of the =
state-of-play<br></blockquote><blockquote type=3D"cite">for these. Feel =
free to reply to the list, or just Kevin<br></blockquote><blockquote =
type=3D"cite">and I. The full list is at [1], but the list that I =
think<br></blockquote><blockquote type=3D"cite">is relevant is below, =
though I may have missed something,<br></blockquote><blockquote =
type=3D"cite">esp. if the file name is odd (note that the list =
omits<br></blockquote><blockquote type=3D"cite">the drafts that are =
already progressing).<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">What I'd like =
is to get is a sense of whether you think<br></blockquote><blockquote =
type=3D"cite">drafts are dead or not, and if not, roughly where you =
think<br></blockquote><blockquote type=3D"cite">your draft is going, =
(and when).<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">If you think =
the draft should live, but no longer have<br></blockquote><blockquote =
type=3D"cite">cycles to work on it, then that's interesting too - =
we<br></blockquote><blockquote type=3D"cite">may be able to recruit some =
new authors.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">I can start the =
ball rolling: I think of =
draft-farrell-dtnrg-km<br></blockquote><blockquote type=3D"cite">as a =
reminder that we've not done much in the way of =
key<br></blockquote><blockquote type=3D"cite">mgmt and should, but the =
draft wasn't ever really aimed<br></blockquote><blockquote =
type=3D"cite">at being an RFC. If someone wanted to revive or replace =
that,<br></blockquote><blockquote type=3D"cite">that'd be fine by =
me.<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote=
 type=3D"cite">Thanks,<br></blockquote><blockquote =
type=3D"cite">Stephen.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">[1] <a =
href=3D"http://tools.ietf.org/id/dtnrg">http://tools.ietf.org/id/dtnrg</a>=
<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">DTNRG non-expired:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">28 Apr 2010 =
&nbsp;<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-bundle-age-block<br></blockquote><blockquote =
type=3D"cite">01 Jun 2010 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>draft-irtf-dtnrg-ecos<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span><br></blockquote><blockquote type=3D"cite">17 May 2010 =
&nbsp;<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-bundle-previous-hop-block<br></blockquote><blockqu=
ote type=3D"cite">08 May 2010 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-bundle-checksum<br></blockquote><blockquote =
type=3D"cite">08 Mar 2010 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>draft-irtf-dtnrg-ipnd<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">DTNRG =
expired:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">05 Oct 2009 =
&nbsp;<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-bundle-retrans-block<br></blockquote><blockquote =
type=3D"cite">12 Aug 2009 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-bundle-divert<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span><br></blockquote><blockquote =
type=3D"cite">12 Aug 2009 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-bundle-encapsulation<span class=3D"Apple-tab-span"=
 style=3D"white-space:pre">	</span><br></blockquote><blockquote =
type=3D"cite">31 Mar 2009 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-dtn-uri-scheme<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span><br></blockquote><blockquote =
type=3D"cite">09 Mar 2009 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-sec-overview<br></blockquote><blockquote =
type=3D"cite">19 Nov 2008 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-udp-clayer<br></blockquote><blockquote =
type=3D"cite">03 Nov 2008 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>draft-irtf-dtnrg-tcp-clayer<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">PERS =
non-expired:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">09 Jul 2010 =
&nbsp;<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-burleigh-dtnrg-cgr<br></blockquote><blockquote =
type=3D"cite">08 May 2010 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-wood-dtnrg-saratoga<br></blockquote><blockquote =
type=3D"cite">08 May 2010 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-wood-dtnrg-http-dtn-delivery<br></blockquote><blockquote =
type=3D"cite">28 Feb 2010 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-fall-dtnrg-schl<br></blockquote><blockquote type=3D"cite">27 =
Feb 2010 &nbsp;<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-mcmahon-dtnrg-dtn-edp<br></blockquote><blockquote =
type=3D"cite">10 Feb 2010 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-burleigh-dtnrg-ltpcl<br></blockquote><blockquote =
type=3D"cite">09 Feb 2010 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-ding-network-management<br></blockquote><blockquot=
e type=3D"cite"><br></blockquote><blockquote type=3D"cite">PERS =
expired:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">26 Oct 2009 =
&nbsp;<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-davies-dtnrg-uri-find<br></blockquote><blockquote =
type=3D"cite">12 Aug 2009 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-symington-dtnrg-bundle-multicast-custodial<br></blockquote><b=
lockquote type=3D"cite">06 Jun 2009 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-ivancic-dtnrg-network-management-reqs<br></blockquote><blockq=
uote type=3D"cite">22 May 2009 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-pbasu-dtnrg-naming<br></blockquote><blockquote =
type=3D"cite">19 Jun 2007 &nbsp;<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>draft-farrell-dtnrg-km<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><blockquote =
type=3D"cite"><br></blockquote>___________________________________________=
____<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></div></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-5--674771453--

From: Hans Kruse <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 29 Jul 2010 14:01:37 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Document status check

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

We can already fragment bundles and use LTP to transmit multiple (LTP)  
frames per bundle.   I am not sure it makes sense to create another  
fragmentation mechanism.....

On Jul 29, 2010, at 12:52 PM, Ivancic, William D. (GRC-RHN0) wrote:

> I concur for TCP.
>
> The current UDP Convergence layer is rather limiting but is  
> implemented in most if not all DTN implementations.  I would rather  
> UDP not have all the limitations it does.  A better UDP convergence  
> layer that doesn't limit one to 64kbyte packets would be preferred.
>
> - Will
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Daniel
>> Ellard
>> Sent: Thursday, July 29, 2010 12:28 PM
>> To: [email-masked]
>> Subject: Re: [dtn-interest] Document status check
>>
>> On 7/29/10 10:59 AM, Stephen Farrell wrote:
>>>
>>> Hi all,
>>>
>>> As usual, there're a bunch of I-Ds with dtnrg in their
>>> name, so I'd just like to get a sense of the state-of-play
>>> for these. Feel free to reply to the list, or just Kevin
>>> and I.
>>> ...
>>> If you think the draft should live, but no longer have
>>> cycles to work on it, then that's interesting too - we
>>> may be able to recruit some new authors.
>>> ...
>>> DTNRG expired:
>>> ...
>>> 19 Nov 2008  	draft-irtf-dtnrg-udp-clayer
>>> 03 Nov 2008  	draft-irtf-dtnrg-tcp-clayer
>>
>> I am not an author or custodian of either of these, but am
>> willing to help keep them moving forward.  We (BBN anyway,
>> but I suspect nearly everyone else) use these all the time
>> and they should be moved forward to RFC status instead of
>> just being de facto standards.
>>
>> -Dan
>>
>> --
>> Daniel Ellard, Ph.D.
>> Senior Scientist, Network Research
>> BBN Technologies
>> 10 Moulton Street
>> Cambridge, MA 02138
>> [email-masked]
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

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

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">We can already fragment bundles =
and use LTP to transmit multiple (LTP) frames per bundle. &nbsp; I am =
not sure it makes sense to create another fragmentation =
mechanism.....<div><br><div><div>On Jul 29, 2010, at 12:52 PM, Ivancic, =
William D. (GRC-RHN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>I =
concur for TCP. &nbsp;<br><br>The current UDP Convergence layer is =
rather limiting but is implemented in most if not all DTN =
implementations. &nbsp;I would rather UDP not have all the limitations =
it does. &nbsp;A better UDP convergence layer that doesn't limit one to =
64kbyte packets would be preferred. <br><br>- Will =
&nbsp;<br><br><blockquote type=3D"cite">-----Original =
Message-----<br></blockquote><blockquote type=3D"cite">From: =
[email-masked] [<a =
href=3D"mailto:dtn-">mailto:dtn-</a><br></blockquote><blockquote =
type=3D"cite"><a =
href=3D"mailto:[email-masked]">interest-bou=
[email-masked]</a>] On Behalf Of =
Daniel<br></blockquote><blockquote =
type=3D"cite">Ellard<br></blockquote><blockquote type=3D"cite">Sent: =
Thursday, July 29, 2010 12:28 PM<br></blockquote><blockquote =
type=3D"cite">To: <a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote =
type=3D"cite">Subject: Re: [dtn-interest] Document status =
check<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">On 7/29/10 =
10:59 AM, Stephen Farrell wrote:<br></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Hi =
all,<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">As usual, there're a bunch of =
I-Ds with dtnrg in their<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">name, so I'd just like to get a =
sense of the state-of-play<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">for these. Feel free to reply to =
the list, or just Kevin<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">and =
I.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">...<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">If you think the draft should =
live, but no longer have<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">cycles to work on it, then =
that's interesting too - we<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">may be able to recruit some new =
authors.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">...<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">DTNRG =
expired:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">...<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">19 Nov 2008 &nbsp;<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-udp-clayer<br></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite">03 Nov 2008 &nbsp;<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-tcp-clayer<br></blockquote></blockquote><blockquot=
e type=3D"cite"><br></blockquote><blockquote type=3D"cite">I am not an =
author or custodian of either of these, but =
am<br></blockquote><blockquote type=3D"cite">willing to help keep them =
moving forward. &nbsp;We (BBN anyway,<br></blockquote><blockquote =
type=3D"cite">but I suspect nearly everyone else) use these all the =
time<br></blockquote><blockquote type=3D"cite">and they should be moved =
forward to RFC status instead of<br></blockquote><blockquote =
type=3D"cite">just being de facto standards.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">-Dan<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">--<br></blockquote><blockquote type=3D"cite">Daniel =
Ellard, Ph.D.<br></blockquote><blockquote type=3D"cite">Senior =
Scientist, Network Research<br></blockquote><blockquote type=3D"cite">BBN =
Technologies<br></blockquote><blockquote type=3D"cite">10 Moulton =
Street<br></blockquote><blockquote type=3D"cite">Cambridge, MA =
02138<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br></blockquote><block=
quote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><br>_______________________________________________<br>dtn-in=
terest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></div></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-4--675897010--

From: Hans Kruse <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Thu, 29 Jul 2010 13:58:58 -0400
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Document status check

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

I plan to update both; probably before September - pending the outcome  
of some feasibility tests we are running now.

> 19 Nov 2008  	draft-irtf-dtnrg-udp-clayer
> 03 Nov 2008  	draft-irtf-dtnrg-tcp-clayer	
>

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

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

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I plan to update both; probably =
before September - pending the outcome of some feasibility tests we are =
running now.<div><br><div><blockquote type=3D"cite"><div>19 Nov 2008 =
&nbsp;<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-udp-clayer<br>03 Nov 2008 &nbsp;<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-irtf-dtnrg-tcp-clayer<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span><br><br></div></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-3--676055956--

From: "Symington, Susan F." <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Thu, 29 Jul 2010 13:33:13 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Document status check

Steven,

>From your list:
1) >17 May 2010  	draft-irtf-dtnrg-bundle-previous-hop-block

I believe that you listed this ID erroneously. It is among the group that Elwyn is helping to progress to RFC status.

2)
>05 Oct 2009  	draft-irtf-dtnrg-bundle-retrans-block
>12 Aug 2009  	draft-irtf-dtnrg-bundle-divert
>12 Aug 2009  	draft-irtf-dtnrg-bundle-encapsulation
>12 Aug 2009  	draft-symington-dtnrg-bundle-multicast-custodial

I believe the above are important, but I currently don't have the cycles to work on them.

The first I-D (retransmission block) is needed in order to distinguish intentional custodial retransmissions from nefarious replays. 

The next two I-Ds (divert and encapsulation) support bundle encapsulation. I thought they were ready to progress and I believe you said you would put them forward after the current batch was taken care of.

The last I-D describes how custodial delivery could be supported for bundles that are being multicasted (RFC 5050 only supports custodial delivery for unicast bundles). Not many readers seem to have paid much attention to this I-D, but it is pretty comprehensive. 

-susan

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Stephen
>Farrell
>Sent: Thursday, July 29, 2010 11:00 AM
>To: DTN
>Subject: [dtn-interest] Document status check
>
>
>Hi all,
>
>As usual, there're a bunch of I-Ds with dtnrg in their
>name, so I'd just like to get a sense of the state-of-play
>for these. Feel free to reply to the list, or just Kevin
>and I. The full list is at [1], but the list that I think
>is relevant is below, though I may have missed something,
>esp. if the file name is odd (note that the list omits
>the drafts that are already progressing).
>
>What I'd like is to get is a sense of whether you think
>drafts are dead or not, and if not, roughly where you think
>your draft is going, (and when).
>
>If you think the draft should live, but no longer have
>cycles to work on it, then that's interesting too - we
>may be able to recruit some new authors.
>
>I can start the ball rolling: I think of draft-farrell-dtnrg-km
>as a reminder that we've not done much in the way of key
>mgmt and should, but the draft wasn't ever really aimed
>at being an RFC. If someone wanted to revive or replace that,
>that'd be fine by me.
>
>Thanks,
>Stephen.
>
>[1] http://tools.ietf.org/id/dtnrg
>
>DTNRG non-expired:
>
>28 Apr 2010  	draft-irtf-dtnrg-bundle-age-block
>01 Jun 2010  	draft-irtf-dtnrg-ecos
>17 May 2010  	draft-irtf-dtnrg-bundle-previous-hop-block
>08 May 2010  	draft-irtf-dtnrg-bundle-checksum
>08 Mar 2010  	draft-irtf-dtnrg-ipnd
>
>DTNRG expired:
>
>05 Oct 2009  	draft-irtf-dtnrg-bundle-retrans-block
>12 Aug 2009  	draft-irtf-dtnrg-bundle-divert
>12 Aug 2009  	draft-irtf-dtnrg-bundle-encapsulation
>31 Mar 2009  	draft-irtf-dtnrg-dtn-uri-scheme
>09 Mar 2009  	draft-irtf-dtnrg-sec-overview
>19 Nov 2008  	draft-irtf-dtnrg-udp-clayer
>03 Nov 2008  	draft-irtf-dtnrg-tcp-clayer
>
>PERS non-expired:
>
>09 Jul 2010  	draft-burleigh-dtnrg-cgr
>08 May 2010  	draft-wood-dtnrg-saratoga
>08 May 2010  	draft-wood-dtnrg-http-dtn-delivery
>28 Feb 2010  	draft-fall-dtnrg-schl
>27 Feb 2010  	draft-mcmahon-dtnrg-dtn-edp
>10 Feb 2010  	draft-burleigh-dtnrg-ltpcl
>09 Feb 2010  	draft-irtf-dtnrg-ding-network-management
>
>PERS expired:
>
>26 Oct 2009  	draft-davies-dtnrg-uri-find
>12 Aug 2009  	draft-symington-dtnrg-bundle-multicast-custodial
>06 Jun 2009  	draft-ivancic-dtnrg-network-management-reqs
>22 May 2009  	draft-pbasu-dtnrg-naming
>19 Jun 2007  	draft-farrell-dtnrg-km
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Sender: [email-masked]
From: Michael Demmer <[email-masked]>
Date: Thu, 29 Jul 2010 10:03:59 -0700
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Document status check

Alternatively the implementation just signals this constraint up from
the convergence layer to the bundle layer which engages the bundle
fragmentation mechanism to break large bundles up into smaller
ones. That was my original design intent for DTN2, but I never got
around to implementing it.

This is analogous to ethernet or other link layer MTU causing IP to
fragment large packets.

One could clearly design other convergence layers over UDP with
features such as fragmentation/reassembly, reliability, congestion
control, etc. From what I recall Saratoga is an example of just such a
protocol. But that doesn't mean there isn't room for a simple
datagram-based convergence layer as well.

-m

On Thu, Jul 29, 2010 at 9:52 AM, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:
> I concur for TCP.
>
> The current UDP Convergence layer is rather limiting but is implemented in most if not all DTN implementations.  I would rather UDP not have all the limitations it does.  A better UDP convergence layer that doesn't limit one to 64kbyte packets would be preferred.
>
> - Will
>
>>-----Original Message-----
>>From: [email-masked] [mailto:dtn-
>>[email-masked]] On Behalf Of Daniel
>>Ellard
>>Sent: Thursday, July 29, 2010 12:28 PM
>>To: [email-masked]
>>Subject: Re: [dtn-interest] Document status check
>>
>>On 7/29/10 10:59 AM, Stephen Farrell wrote:
>>>
>>> Hi all,
>>>
>>> As usual, there're a bunch of I-Ds with dtnrg in their
>>> name, so I'd just like to get a sense of the state-of-play
>>> for these. Feel free to reply to the list, or just Kevin
>>> and I.
>>>...
>>> If you think the draft should live, but no longer have
>>> cycles to work on it, then that's interesting too - we
>>> may be able to recruit some new authors.
>>> ...
>>> DTNRG expired:
>>>...
>>> 19 Nov 2008          draft-irtf-dtnrg-udp-clayer
>>> 03 Nov 2008          draft-irtf-dtnrg-tcp-clayer
>>
>>I am not an author or custodian of either of these, but am
>>willing to help keep them moving forward.  We (BBN anyway,
>>but I suspect nearly everyone else) use these all the time
>>and they should be moved forward to RFC status instead of
>>just being de facto standards.
>>
>>-Dan
>>
>>--
>>Daniel Ellard, Ph.D.
>>Senior Scientist, Network Research
>>BBN Technologies
>>10 Moulton Street
>>Cambridge, MA 02138
>>[email-masked]
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Daniel Ellard <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 29 Jul 2010 11:52:24 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Document status check

I concur for TCP.  

The current UDP Convergence layer is rather limiting but is implemented in most if not all DTN implementations.  I would rather UDP not have all the limitations it does.  A better UDP convergence layer that doesn't limit one to 64kbyte packets would be preferred. 

- Will  

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Daniel
>Ellard
>Sent: Thursday, July 29, 2010 12:28 PM
>To: [email-masked]
>Subject: Re: [dtn-interest] Document status check
>
>On 7/29/10 10:59 AM, Stephen Farrell wrote:
>>
>> Hi all,
>>
>> As usual, there're a bunch of I-Ds with dtnrg in their
>> name, so I'd just like to get a sense of the state-of-play
>> for these. Feel free to reply to the list, or just Kevin
>> and I.
>>...
>> If you think the draft should live, but no longer have
>> cycles to work on it, then that's interesting too - we
>> may be able to recruit some new authors.
>> ...
>> DTNRG expired:
>>...
>> 19 Nov 2008  	draft-irtf-dtnrg-udp-clayer
>> 03 Nov 2008  	draft-irtf-dtnrg-tcp-clayer
>
>I am not an author or custodian of either of these, but am
>willing to help keep them moving forward.  We (BBN anyway,
>but I suspect nearly everyone else) use these all the time
>and they should be moved forward to RFC status instead of
>just being de facto standards.
>
>-Dan
>
>--
>Daniel Ellard, Ph.D.
>Senior Scientist, Network Research
>BBN Technologies
>10 Moulton Street
>Cambridge, MA 02138
>[email-masked]
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 29 Jul 2010 19:35:58 +0300
From: Joerg Ott <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Document status check

Hi,

I had an update to tcpcl on my list, but it just did not
make this.  This doc is mostly done.  We raised some
implementation issues at some point, but nothing conclusive
resulted from the discussion.  So, we may as well go ahead.

Joerg

Stephen Farrell wrote:
> Hi all,
> 
> As usual, there're a bunch of I-Ds with dtnrg in their
> name, so I'd just like to get a sense of the state-of-play
> for these. Feel free to reply to the list, or just Kevin
> and I. The full list is at [1], but the list that I think
> is relevant is below, though I may have missed something,
> esp. if the file name is odd (note that the list omits
> the drafts that are already progressing).
> 
> What I'd like is to get is a sense of whether you think
> drafts are dead or not, and if not, roughly where you think
> your draft is going, (and when).
> 
> If you think the draft should live, but no longer have
> cycles to work on it, then that's interesting too - we
> may be able to recruit some new authors.
> 
> I can start the ball rolling: I think of draft-farrell-dtnrg-km
> as a reminder that we've not done much in the way of key
> mgmt and should, but the draft wasn't ever really aimed
> at being an RFC. If someone wanted to revive or replace that,
> that'd be fine by me.
> 
> Thanks,
> Stephen.
> 
> [1] http://tools.ietf.org/id/dtnrg
> 
> DTNRG non-expired:
> 
> 28 Apr 2010  	draft-irtf-dtnrg-bundle-age-block
> 01 Jun 2010  	draft-irtf-dtnrg-ecos	
> 17 May 2010  	draft-irtf-dtnrg-bundle-previous-hop-block
> 08 May 2010  	draft-irtf-dtnrg-bundle-checksum
> 08 Mar 2010  	draft-irtf-dtnrg-ipnd	
> 
> DTNRG expired:
> 
> 05 Oct 2009  	draft-irtf-dtnrg-bundle-retrans-block
> 12 Aug 2009  	draft-irtf-dtnrg-bundle-divert	
> 12 Aug 2009  	draft-irtf-dtnrg-bundle-encapsulation	
> 31 Mar 2009  	draft-irtf-dtnrg-dtn-uri-scheme	
> 09 Mar 2009  	draft-irtf-dtnrg-sec-overview
> 19 Nov 2008  	draft-irtf-dtnrg-udp-clayer
> 03 Nov 2008  	draft-irtf-dtnrg-tcp-clayer	
> 
> PERS non-expired:
> 
> 09 Jul 2010  	draft-burleigh-dtnrg-cgr
> 08 May 2010  	draft-wood-dtnrg-saratoga
> 08 May 2010  	draft-wood-dtnrg-http-dtn-delivery
> 28 Feb 2010  	draft-fall-dtnrg-schl
> 27 Feb 2010  	draft-mcmahon-dtnrg-dtn-edp
> 10 Feb 2010  	draft-burleigh-dtnrg-ltpcl
> 09 Feb 2010  	draft-irtf-dtnrg-ding-network-management
> 
> PERS expired:
> 
> 26 Oct 2009  	draft-davies-dtnrg-uri-find
> 12 Aug 2009  	draft-symington-dtnrg-bundle-multicast-custodial
> 06 Jun 2009  	draft-ivancic-dtnrg-network-management-reqs
> 22 May 2009  	draft-pbasu-dtnrg-naming
> 19 Jun 2007  	draft-farrell-dtnrg-km
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Jordan Hayes" <[email-masked]>
To: "DTN Interest" <[email-masked]>
Date: Thu, 29 Jul 2010 09:36:30 -0700
Subject: [dtn-interest] AX.25 / Packet radio convergence layer ...?

Has anyone looked into this?

/jordan

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Thu, 29 Jul 2010 17:28:03 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Subject: Re: [dtn-interest] Document status check

draft-irtf-dtnrg-bundle-checksum depends heavily on draft-irtf-dtnrg-bundle-security, so let's wait until that gets through publication before considering the checksum draft. Like bundle security, it would be experimental, I think. (The security-16 draft doesn't state intended status at top, but given the SHOULD MUST language, it must be intended as experimental.)

draft-wood-dtnrg-saratoga relies heavily on draft-wood-tsvwg-saratoga, so would really need publishing after that. It does read more as informational, but a lot of experiments from space carrying bundles over Saratoga have been done [1], so experimental is likely most appropriate. (And some of its informative references are probably really normative - the tsvwg draft, for one. Can an informative draft have normative references?)

draft-wood-dtnrg-http-dtn-delivery is intended as experimental.

These drafts are not dead, and are not expired.

[1] Oh, btw, a paper describing some of the more recent tests with Saratoga carrying bundles from space is now available:

http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#globecom-transfer
Will Ivancic, Phil Paulsen, Dave Stewart, John Taylor, Scott Lynch,
Jay Heberle, James Northam, Chris Jackson and Lloyd Wood, 'Large
Large File Transfers from Space using Multiple Ground Terminals and
Delay-Tolerant Networking', refereed conference paper, IEEE Global
Communications Conference (Globecom 2010), Miami, Florida, December 2010.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: 29 July 2010 15:59
To: DTN
Subject: [dtn-interest] Document status check

Hi all,

As usual, there're a bunch of I-Ds with dtnrg in their
name, so I'd just like to get a sense of the state-of-play
for these. Feel free to reply to the list, or just Kevin
and I. The full list is at [1], but the list that I think
is relevant is below, though I may have missed something,
esp. if the file name is odd (note that the list omits
the drafts that are already progressing).

What I'd like is to get is a sense of whether you think
drafts are dead or not, and if not, roughly where you think
your draft is going, (and when).

If you think the draft should live, but no longer have
cycles to work on it, then that's interesting too - we
may be able to recruit some new authors.

I can start the ball rolling: I think of draft-farrell-dtnrg-km
as a reminder that we've not done much in the way of key
mgmt and should, but the draft wasn't ever really aimed
at being an RFC. If someone wanted to revive or replace that,
that'd be fine by me.

Thanks,
Stephen.

[1] http://tools.ietf.org/id/dtnrg

DTNRG non-expired:

28 Apr 2010     draft-irtf-dtnrg-bundle-age-block
01 Jun 2010     draft-irtf-dtnrg-ecos
17 May 2010     draft-irtf-dtnrg-bundle-previous-hop-block
08 May 2010     draft-irtf-dtnrg-bundle-checksum
08 Mar 2010     draft-irtf-dtnrg-ipnd

DTNRG expired:

05 Oct 2009     draft-irtf-dtnrg-bundle-retrans-block
12 Aug 2009     draft-irtf-dtnrg-bundle-divert
12 Aug 2009     draft-irtf-dtnrg-bundle-encapsulation
31 Mar 2009     draft-irtf-dtnrg-dtn-uri-scheme
09 Mar 2009     draft-irtf-dtnrg-sec-overview
19 Nov 2008     draft-irtf-dtnrg-udp-clayer
03 Nov 2008     draft-irtf-dtnrg-tcp-clayer

PERS non-expired:

09 Jul 2010     draft-burleigh-dtnrg-cgr
08 May 2010     draft-wood-dtnrg-saratoga
08 May 2010     draft-wood-dtnrg-http-dtn-delivery
28 Feb 2010     draft-fall-dtnrg-schl
27 Feb 2010     draft-mcmahon-dtnrg-dtn-edp
10 Feb 2010     draft-burleigh-dtnrg-ltpcl
09 Feb 2010     draft-irtf-dtnrg-ding-network-management

PERS expired:

26 Oct 2009     draft-davies-dtnrg-uri-find
12 Aug 2009     draft-symington-dtnrg-bundle-multicast-custodial
06 Jun 2009     draft-ivancic-dtnrg-network-management-reqs
22 May 2009     draft-pbasu-dtnrg-naming
19 Jun 2007     draft-farrell-dtnrg-km

Date: Thu, 29 Jul 2010 12:28:02 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: [email-masked]
Subject: Re: [dtn-interest] Document status check

On 7/29/10 10:59 AM, Stephen Farrell wrote:
>
> Hi all,
>
> As usual, there're a bunch of I-Ds with dtnrg in their
> name, so I'd just like to get a sense of the state-of-play
> for these. Feel free to reply to the list, or just Kevin
> and I.
>...
> If you think the draft should live, but no longer have
> cycles to work on it, then that's interesting too - we
> may be able to recruit some new authors.
> ...
> DTNRG expired:
>...
> 19 Nov 2008  	draft-irtf-dtnrg-udp-clayer
> 03 Nov 2008  	draft-irtf-dtnrg-tcp-clayer	

I am not an author or custodian of either of these, but am 
willing to help keep them moving forward.  We (BBN anyway, 
but I suspect nearly everyone else) use these all the time 
and they should be moved forward to RFC status instead of 
just being de facto standards.

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

Date: Thu, 29 Jul 2010 15:59:34 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Document status check

Hi all,

As usual, there're a bunch of I-Ds with dtnrg in their
name, so I'd just like to get a sense of the state-of-play
for these. Feel free to reply to the list, or just Kevin
and I. The full list is at [1], but the list that I think
is relevant is below, though I may have missed something,
esp. if the file name is odd (note that the list omits
the drafts that are already progressing).

What I'd like is to get is a sense of whether you think
drafts are dead or not, and if not, roughly where you think
your draft is going, (and when).

If you think the draft should live, but no longer have
cycles to work on it, then that's interesting too - we
may be able to recruit some new authors.

I can start the ball rolling: I think of draft-farrell-dtnrg-km
as a reminder that we've not done much in the way of key
mgmt and should, but the draft wasn't ever really aimed
at being an RFC. If someone wanted to revive or replace that,
that'd be fine by me.

Thanks,
Stephen.

[1] http://tools.ietf.org/id/dtnrg

DTNRG non-expired:

28 Apr 2010  	draft-irtf-dtnrg-bundle-age-block
01 Jun 2010  	draft-irtf-dtnrg-ecos	
17 May 2010  	draft-irtf-dtnrg-bundle-previous-hop-block
08 May 2010  	draft-irtf-dtnrg-bundle-checksum
08 Mar 2010  	draft-irtf-dtnrg-ipnd	

DTNRG expired:

05 Oct 2009  	draft-irtf-dtnrg-bundle-retrans-block
12 Aug 2009  	draft-irtf-dtnrg-bundle-divert	
12 Aug 2009  	draft-irtf-dtnrg-bundle-encapsulation	
31 Mar 2009  	draft-irtf-dtnrg-dtn-uri-scheme	
09 Mar 2009  	draft-irtf-dtnrg-sec-overview
19 Nov 2008  	draft-irtf-dtnrg-udp-clayer
03 Nov 2008  	draft-irtf-dtnrg-tcp-clayer	

PERS non-expired:

09 Jul 2010  	draft-burleigh-dtnrg-cgr
08 May 2010  	draft-wood-dtnrg-saratoga
08 May 2010  	draft-wood-dtnrg-http-dtn-delivery
28 Feb 2010  	draft-fall-dtnrg-schl
27 Feb 2010  	draft-mcmahon-dtnrg-dtn-edp
10 Feb 2010  	draft-burleigh-dtnrg-ltpcl
09 Feb 2010  	draft-irtf-dtnrg-ding-network-management

PERS expired:

26 Oct 2009  	draft-davies-dtnrg-uri-find
12 Aug 2009  	draft-symington-dtnrg-bundle-multicast-custodial
06 Jun 2009  	draft-ivancic-dtnrg-network-management-reqs
22 May 2009  	draft-pbasu-dtnrg-naming
19 Jun 2007  	draft-farrell-dtnrg-km

Date: Thu, 29 Jul 2010 15:50:57 +0200
From: Simon Perreault <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...

Peter Lovell wrote, on 07/29/2010 03:48 PM:
> the most recent BSP draft (-16) includes the registry info.

I'm sorry, I looked at an older version.

Thanks!
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

From: Peter Lovell <[email-masked]>
To: Simon Perreault <[email-masked]>, [email-masked], Marc Blanchet <[email-masked]>
Date: Thu, 29 Jul 2010 09:48:27 -0400
Subject: [dtn-interest] Re(2): draft-irtf-dtnrg-bp-iana-registries ready to go...

On Thu, Jul 29, 2010, Simon Perreault <[email-masked]> wrote:

>- At <http://www.dtnrg.org/wiki/AssignedNamesAndNumbers> there is a registry
>named "Cipher Suites used in the Bundle Security Protocols". Can we expect a
>later revision of draft-irtf-dtnrg-bundle-security to contain this
registry in
>its IANA Considerations section, or should this draft include it? I think the
>former would be preferable.

Hi Simon,

the most recent BSP draft (-16) includes the registry info.

Cheers.....Peter

Date: Thu, 29 Jul 2010 15:41:45 +0200
From: Simon Perreault <[email-masked]>
To: [email-masked], Marc Blanchet <[email-masked]>
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...

Stephen Farrell wrote, on 07/29/2010 02:59 PM:
> Please read and comment in the next month (giving longer for
> vacations), since this the other documents will (at some stage)
> block on this.

I just read it. Some comments:

- The document cites the Licklider RFC but does not define any registry related
to it. Is this intentional? I find it at least a bit confusing.

- At <http://www.dtnrg.org/wiki/AssignedNamesAndNumbers> there is a registry
named "Cipher Suites used in the Bundle Security Protocols". Can we expect a
later revision of draft-irtf-dtnrg-bundle-security to contain this registry in
its IANA Considerations section, or should this draft include it? I think the
former would be preferable.

- In section 2.3, since this is an SDNV, and RFC 5050 says that implementations
may ignore SDNVs larger than 2^64, could we say that the range is "0 to 63"
instead of "variable"? Then list 21-63 as Unassigned. This would better reflect
the actual, practical range.

- Same comment for 2.4. Suggestion: range should be "0 to 63" and 7-63 should be
listed as Unassigned.

Minor/editorial:

- In section 2.5, can we make the left column have the same format as in
sections 2.3 and 2.4? That is, instead of listing binary values, list bit position.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>, dtn interest <[email-masked]>
Date: Thu, 29 Jul 2010 09:27:26 -0400
Subject: Re: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...

On Thu, Jul 29, 2010, Stephen Farrell <[email-masked]> wrote:

>
>This document [1] creates and populates IANA registries for the BP
>that are needed by some of the I-Ds we're trying to turn into RFCs
>now.
>
>I think its ready to go to the IRSG for review.
>
>Please read and comment in the next month (giving longer for
>vacations), since this the other documents will (at some stage)
>block on this.
>
>Deadline for comments is end of August.
>
>A couple of messages saying "this is good to go" would be
>useful.
>
>If there are minor editorial comments we can process those as
>we go, so do send those as well, but in that case, please be
>clear as to whether or not you think this should be progressed
>now regardless of your editorial comments.
>
>Thanks,
>Stephen.

Hi Stephen,

I looked through this when I was adding similar things to BSP draft.

I vote that "this is good to go"

Cheers.....Peter

Date: Thu, 29 Jul 2010 13:59:47 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] draft-irtf-dtnrg-bp-iana-registries ready to go...

This document [1] creates and populates IANA registries for the BP
that are needed by some of the I-Ds we're trying to turn into RFCs
now.

I think its ready to go to the IRSG for review.

Please read and comment in the next month (giving longer for
vacations), since this the other documents will (at some stage)
block on this.

Deadline for comments is end of August.

A couple of messages saying "this is good to go" would be
useful.

If there are minor editorial comments we can process those as
we go, so do send those as well, but in that case, please be
clear as to whether or not you think this should be progressed
now regardless of your editorial comments.

Thanks,
Stephen.

[]1 http://tools.ietf.org/html/draft-irtf-dtnrg-iana-bp-registries

Date: Mon, 26 Jul 2010 12:57:01 -0400
From: "Daniel W. Brown" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Age Block I-D

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

Hi all,

I'm unable to attend IETF 78 and it's been suggested that I post the Age
Block I-D source.  Please find attached.

For all attending, hope you enjoy Maastricht!

Thanks.

Dan

--------------070404090308090808070100
Content-Type: text/xml;
 name="draft-irtf-dtnrg-bundle-age-block.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-age-block.xml"

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc1112 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112.xml'>
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc3171 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3171.xml'>
    <!ENTITY rfc3376 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml'>
    <!ENTITY rfc3927 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml'>
    <!ENTITY rfc3986 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'>
    <!ENTITY rfc4838 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4838.xml'>
    <!ENTITY rfc5050 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml'>
    <!ENTITY I-D.irtf-dtnrg-bundle-security PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-irtf-dtnrg-bundle-security-15.xml'>
]>

<!-- TODO:  authors, references -->

<rfc category="exp" ipr="trust200902" docName="draft-irtf-dtnrg-bundle-age-block-00">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>

<!-- 
    $Id$
    $Author$
    $Date$
-->

<front>
  <title abbrev="DTN-AGE">DTN Bundle Age Block for Expiration without UTC</title>

  <author initials="D." surname="Brown" fullname="Daniel W. Brown">
    <organization>
      Raytheon BBN Technologies
    </organization>
    <address>
      <postal>
        <street>10 Moulton St.</street>
        <city>Cambridge</city> <region>MA</region>
        <code>02138</code>
        <country>US</country>
      </postal>
      <email>[email-masked]</email>
    </address>
  </author>

  <author initials="S." surname="Farrell" fullname="Stephen Farrell">
    <organization>Trinity College Dublin</organization>
    <address>
      <postal>
        <street>Distributed Systems Group</street>
        <street>Department of Computer Science</street>
        <street>Trinity College </street>
        <city>Dublin</city>
        <code>2</code>
        <country>Ireland</country>
      </postal>
      <phone>+353-1-896-2354</phone>
      <email>[email-masked]</email>
    </address>
  </author>

  <author fullname="Scott Burleigh" initials="S.B." surname="Burleigh">
    <organization>Jet Propulsion Laboratory</organization>
    <address>
      <postal>
        <street>4800 Oak Grove Drive, m/s 301-490</street>
        <city>Pasadena</city>
        <region>California</region>
        <code>91109</code>
        <country>USA</country>
        </postal>
      <phone>+1-818-393-3353</phone>
      <email>[email-masked]</email>
    </address>
  </author>

  <date/>

  <abstract>
    <t>
    As originally specified, <xref target='RFC5050'/> presumes that any DTN
    node will have access to accurate real world time.
    Experience has shown that there are devices and networks
    where accurate real world time is difficult or impossible
    to consistently obtain.
    </t>

    <t>
    This draft proposes an extension
    block that contains the current age of a bundle in order
    to support bundle expiration for nodes and networks that
    have faulty, intermittent, or no notion of the real world
    time.  Bundle age may be used to expire bundles by a
    Bundle Protocol Agent which does not have access to
    accurate real world time.  The Age must be updated at each
    hop in order to maintain accuracy.
    </t>
  </abstract>

</front>

<middle>

  <section title="Requirements Terminology">
      <t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
      </t>
  </section>

  <section title="Other Terminology">
    <t> This document distinguishes between devices which are only able to
    measure elapsed time and those which have access to global time.  Access
    to global time will be referred to as Coordinated Universal Time (UTC)
    whether the node stores UTC directly or can infer it based on the
    local wall clock time and current time zone.  Devices which do
    not have access to UTC will be referred to as having "node local" or
    just "local" time. </t>

    <t> Accuracy refers to the ability of a node to maintain correct elapsed
    or UTC time since the last synchronization information received.  Lack
    of accuracy is also referred to as clock drift. </t>

    <t> Precision refers to the granularity of the time representation.  For example,
    microseconds is higher precision than milliseconds. </t>
  </section>

  <section title="Introduction">
    <t> Experience has shown that clock drift in DTN nodes is sometimes unavoidable and
    has detrimental effects on the protocol.  The detrimental effects are
    magnified for bundles sourced with short lifetimes. </t>

    <t> Additionally, <xref target='RFC5050'/> compliance is not possible when devices
    do not have access to accurate UTC via either synchronization or an accurate, persistent
    battery-backed UTC clock.  An <xref target='RFC5050'/>-compliant DTN implementation currently
    requires either an accurate UTC clock or a battery-backed RTC and the
    consistent availability of synchronization signals. </t>
    
    <t> There is a variety of scenarios where neither of these requirements can
    be met.  Many COTS devices such as cell phones, smartphones, and military
    radios contain no internal battery suitable for a persistent RTC,
    and so provide no time when powered on outside the reach of provider infrastructure. </t>

    <t> In the case of smartphones, these devices
    are generally tamper-resistent and as such offer no reasonable means for
    changing an internal battery.  Military devices tend to eschew internal
    consumer oriented batteries which may leak, preferring instead external
    hardened battery packs which may be disconnected frequently,
    making a persistent clock impractical. </t>
  </section>

  <section title="Age Extension Block">
    <t> This document proposes an Age Extension Block (AEB),
    which denotes the time since the bundle has been created, with microsecond
    precision. </t>

    <t> The Age Extension Block format below includes the <xref target='RFC5050'/> required
    block header fields. </t>

    <figure title="">
      <artwork>
+----------------+----------------+-------------------+------------+
|  Block type    | Proc. Flags (*)|  Block length(*)  |   Age(*)   |
+----------------+----------------+-------------------+------------+
    
(*) Self-Delimiting Numeric Values (SDNVs).  See RFC 5050 Sec. 4.1
      </artwork>
    </figure>

    <t> Support for the AEB by BPA implementations is RECOMMENDED for
    interoperability but not required. </t>

    <t> The Age field is defined to represent the approximate elapsed number of
    microseconds since the creation of the bundle. </t>

    <t> The "Block must be replicated in every fragment" bit must be set
    for the AEB.  This also dictates that the AEB must occur before the
    payload block per <xref target='RFC5050'/> Sec. 4.3. </t>

  </section>

  <section title="Applicability">
    <t> Tracking bundle age solely via the AEB
    is insufficient for applications where a bundle spends an
    indeterminate amount of time in suspension.  When a bundle with
    a zero-valued CreationTimestamp is stored to persistent media, for example,
    and the time of its storage is unknown or inaccurate, its age cannot
    in general be determined with any reasonable accuracy upon later
    being accessed. </t>

    <t> An example of this situation is when a bundle with a zero-valued
    CreationTime is stored on a USB mass storage device regardless of whether
    it is treated as a DTN link or node.  Unless the
    time of storage is tracked separately or known to be accurately stored
    on the filesystem, then the Age is unknown upon access. </t>

    <t> See also <xref target="upon_access_from_storage"/>. </t>
  </section>

  <section title="Age Block Processing">
  
    <section title="At Nodes without AEB Support" anchor="no_aeb_support">
      <t> Nodes which do not support the AEB must have access to UTC time and
      therefore can only expire bundles on the basis described in <xref target='RFC5050'/>.</t>

      <t> To improve interoperability with BPAs
      that implement the support for the AEB, whenever a BPA that does not
      support processing the AEB receives a bundle with creation time
      zero the BPA MAY use zero as 'the current time' for the purposes of
      section 5.5 of RFC5050 with respect to treatment of that bundle.
      When implemented, this mechanism prevents deletion of the bundle due to an
      incorrectly computed expiration time. </t>

      <t> All further specification of AEB treatment applies only to nodes
      which support the AEB unless stated otherwise. </t>
    </section>

    <section title="At nodes with AEB support">
      <t> It is expected that implementations which support the AEB will have a means
      of tracking the elapsed time a bundle is resident at a node in order to
      appropriately update the AEB age field upon delivery to a local endpoint or
      forwarding to another node, or to determine the time a bundle should
      be expired.</t>
    </section>

    <section title="Expiration">
      <t> If the AEB is supported by a receiving node, the bundle MUST be treated
      as expired if Age > Lifetime. </t>
    </section>

    <section title="Upon Bundle Creation">

      <t> Since a zero-valued Creation Time field is used to signal that the sender
      does not have access to accurate UTC, then a BPA MUST NOT create a bundle with
      both a zero-valued Creation Time and no AEB. </t>

      <t> For the sake of interoperability it is RECOMMENDED that an AEB be
      provided whenever it is not impractical to do so. </t>

      <section title="At nodes with UTC">
        <t> There may be DTNs where all nodes have accurate realtime clocks, and bundles
        are not expected to travel to other networks.  In these cases, A BPA MAY
        add a bundle age extension block when creating a bundle. In all other cases,
        where it is possible that bundles may be received by nodes without
        accurate realtime clocks, the AEB SHOULD be added at creation time. </t>

        <t> If the BPA has access to UTC upon creation of a bundle, it SHOULD
        place the current UTC into the Creation Timestamp field when creating
        a bundle. </t>
      </section>

      <section title="At nodes without UTC">
        <t> If a BPA does not have access to UTC or chooses not to set the Creation
        Timestamp on UTC, a BPA MUST create an AEB with value 0 and set the Lifetime
        field to the desired time to live for the bundle. </t>
      </section>

    </section>
    
    <section title="Upon BPA Enqueuing to CLA">
      <section title="At nodes with UTC">
        <t> Any time a bundle is enqueued at a CLA for transmission by
        a BPA with access to UTC, the BPA SHOULD first update the AEB age field as
        UTC - CreationTimestamp.  This applies whether the bundle originated
        at the node or this node is forwarding a bundle originating at
        another node. </t>
      </section>
      <section title="At nodes without UTC">
        <t> If UTC is unavailable, the AEB age field should be increased
        by the time which has elapsed since the age field was last updated or
        if the age field was not updated, by the elapsed time since the bundle
        was received.  This applies whether the bundle originated
        at the node or this node is forwarding a bundle originating at
        another node. </t>
      </section>
    </section>

    <section title="Upon Retrieval from Persistent Storage"
             anchor="upon_access_from_storage">

      <t> A bundle with a zero-valued CreationTime and with an
      indeterminate age SHOULD be treated as expired upon being read from
      persistent storage.  This situation arises, for example, when a node
      without access to UTC accesses bundles from persistent storage after
      power cycling.  Such a node cannot determine the elapsed time that
      a bundle has spent in persistent storage across power cycles. </t>

      <t> Bundles with a non-zero CreationTime MAY be forwarded since it
      may be possible for some node with UTC to accurately update the AEB age
      field. </t>

    </section>
    
    <section title="At CLA Transmission and Reception">
      <t> In some networks a convergence layer and/or the CLA may impose
      non-negligible delays.  In deep space networks, propagation delay can
      be significant.  Other CLAs may impose other delays, for example
      CLAs which provide some notion of reliable delivery to multiple
      neighbors. </t>

      <t> A CLA SHOULD convey additional delays imposed either by non-neglible
      propagation delay or non-negligible queuing delay at the CLA.  The
      CLA implementation should make provisions for either the sender or
      receiver or some combination of sender and receiver to provide this
      information.</t>

      <t> This representation SHOULD be made available to the receiving BPA 
      as an elapsed value conveyed by the CLA to the BPA with the bundle. </t>
    </section>
    
    <section title="Upon Reception by BPA">
        <t> In general, a DTN node should maintain an accurate representation of
        a bundle's age so that the bundle can be accurately expired and the
        AEB field can be accurately maintained across transmissions.  Each
        time the bundle is delivered to a local endpoint or forwarded to another
        node, the AEB should be made to reflect the
        age of the bundle as accurately as possible.  This implies that nodes
        without UTC will need to store the UTC or node-local time associated
        with the reception of a bundle in order to later determine the elapsed
        resident time and accurately update the AEB age field upon transmission
        or delivery, or to determine the UTC or node-local time at which the bundle
        should expire.  The age field is updated as
        Age = Age + ElapsedTime, where ElapsedTime = NodeLocalTime - RecordedNodeLocalTime or
        ElapsedTime = UTC - RecordedUTC. </t>

        <t> The BPA SHOULD take into account elapsed time spent at a CLA if the
        CLA provides this information.  The age field should be updated upon
        reception by the BPA in this case by Age = Age + ElapsedTimeAtCLA.</t>
    </section>
    
    <section title="While Bundle Resident at BPA">
      <t> A resident bundle whose age exceeds its lifetime while residing at a node
      should be expired.  Note that age in this context needs to include the bundle's
      AEB age field and any elapsed time while resident at the node which is not
      presently accounted for in the age field. </t>
    </section>
    
  </section>

  <section title="Interoperability">
    <t> Interoperability can be achieved between nodes which support AEB or between nodes
    which have access to UTC.  Since the AEB provides the necessary time
    information for a node without UTC to process the bundle, the only circumstance
    in which interoperability cannot be achieved is between an implementation which
    does not support the AEB (and which therefore must have access to UTC), and
    another node which does not have access to UTC.</t>

    <t> If a bundle is sourced by a UTC node without an AEB, nodes without UTC
    cannot reasonably process the bundle.  If a bundle is sourced by a node
    without UTC (and must therefore have an AEB), this bundle cannot be
    reasonably processed by a UTC node which has no AEB support (with the 
    possible exception of being allowed to forward the bundle without delay, see
    <xref target="no_aeb_support"/>).</t>

    <t> This interoperability issue may be partly mitigated by the provision
    of a gateway node which adds AEB extension blocks to bundles which are
    sourced without one.  This allows nodes without UTC to process bundles sourced
    by UTC nodes that do not support the AEB. </t>

    <t> For the time being, interoperability can only be fully realized in
    networks which contain only nodes with UTC or in networks where all nodes
    implement the AEB.  See <xref target="age_in_primary_block"/>. </t>
    
    <section title="Bundle Forwarding Examples">
      <section title="UTC to non-UTC">
        <t> A UTC node which supports the age extension block creates a bundle which
        has a UTC timestamp for the creation field, and presumably a small or zero-valued
        AEB age field.  The bundle is forwarded to a non-UTC node.  The non-UTC node
        examines the age field, compares Age to Lifetime and determines that the bundle
        is still valid.  The node also associates the node-local time with the bundle
        as soon as it arrives.  Upon retransmitting the bundle or delivering the bundle
        to an application, presuming it has not expired, the node calculates the
        AEB age field as:  Age = Age + UTC - RecordedUTC. </t>
      </section>
      <section title="Non-UTC to UTC">
        <t> A Non-UTC node can only process bundles which have an AEB and so we can presume
        that a bundle forwarded from a Non-UTC node has an AEB.  We will also presume
        for this example that the bundle originated like it did in the previous example
        at a UTC node and therefore has a non-zero CreationTimestamp.  In this case the
        bundle arrives at the receiving UTC node which, seeing the non-zero CreationTimestamp
        ignores the AEB and processes the bundle as described in RFC 5050.  Upon forwarding
        the bundle to a next hop, the UTC node updates the Age field as:
        Age = UTC - CreationTimestamp. </t>
 
        <t> If the bundle was instead sourced at a Non-UTC node, then the bundle has a
        zero-valued CreationTimestamp.  Upon receiving this bundle, the UTC node records
        the bundle's UTC time of arrival.  Upon transmitting or delivering this bundle,
        the node updates the AEB age field based on UTC - RecordedBundleUTC. </t>
      </section>
    </section>

    <section title="Interaction with Fragmentation">
      <t> A BPA needs to fragment a bundle which is larger than the MTU imposed by the
      CLA over which the bundle will be forwarded.  In that case, the BPA creates bundle
      fragments which are themselves bundles.  These bundles may be forwarded at different
      times and therefore must carry different age values.  Because of this, the
      "Block must be replicated in every fragment" bit must be set for the AEB, and each
      bundle fragment must have its AEB age field appropriately set according to the
      specifications contained here. </t>
    </section>

    <section title="Security">
      <t> When security is a concern and since the AEB age field can change at each hop,
      the AEB MAY be encrypted on a hop-by-hop basis via the Bundle Security Protocol
      provided by <xref target="I-D.irtf-dtnrg-bundle-security"/> Section 2.5.
      In that case, the Security-destination MUST be present and MUST specify
      the EID of the next forwarding hop. </t>
    </section>

  </section>

  <section title="Future Considerations">

    <section title="IANA Considerations">
      <t> An IANA block type registration for the AEB will need eventually be created. </t>
    </section>

    <section title="Incorporation of Age into Bundle Primary Block" anchor="age_in_primary_block">
      <t> It is strongly recommended that specification of Age at bundle inception
      and the processing of Age values become mandated by moving the Age value
      in some form into the Bundle primary block at some future time.
      This will improve interoperability and precision of bundle expiration
      without detrimental effect on expiration semantics for current <xref target='RFC5050'/> 
      implementations. </t>
    </section>

    <section title="Margin of Error for Time Values">
      <t> As previously shown, the AEB's age may contain some error.  Propagation
      delay that is difficult or impossible to account for is one potential source
      of error.  This type of error may accumulate at each hop.  Another potential
      source of error is an inaccurate RTC.  Nodes which have a somewhat
      synchronized but potentially inaccurate clock require some means for
      expressing the potential inaccuracy of Creation timestamps for sourced bundles. </t>

      <t> In the former case, a Margin Of Error (MOE) field associated with the Age value
      seems like a reasonable mechanism for extending bundle lifetime in the face
      of accumulated Age error.  The MOE field represents plus-or-minus uncertainty.
      For example, a 5 second MOE indicates that the Age is expected to be accurate
      to within +/- 5 seconds. </t>

      <t> A bundle SHOULD NOT be considered expired unless Age - AgeMOE - CreationMOE > Lifetime. </t>

      <t> In the latter case, a node with a somewhat synchronized RTC might create
      bundles with a non-zero Creation timestamp.  In this case, the Age value can
      be considered a more accurate representation of the bundle's age than
      CurrentTime - CreationTime.  However, without being able to represent this
      state of affairs, a node with an accurate RTC may incorrectly adjust the Age
      value since it may only presume that the CreationTime is accurate. </t>

      <t> Considering MOE values for Age, Creation, RTC, the bundle SHOULD be expired
      if and only if Age - CreationMOE - AgeMOE > Lifetime or RTC - RTCMOE > Lifetime. </t>

      <t> Here is a graphical depiction of MOE for Age, Creation time and RTC: </t>

      <figure title="Margin of Error">
      <artwork>
 ================== Lifetime ====================
                       |
                   ____|
                       |\
             + RTCMOE  | \
                   ----|  } &lt;-- RTC
             - RTCMOE  | /
                   ____|/
                       |
                       |____
                      /|
                     / |   + AgeMOE
            Age --&gt; {  |----
                     \ |   - AgeMOE
                      \|____
                       |
                       |
                       |____
                      /| 
                     / |   + CreationMOE
       Creation --&gt; {  |--
                     \ |   - CreationMOE
                      \|____
                       |
      </artwork>
      </figure>

      <t> This would seem to argue for an eventual specification of margin of error
      for some or all time fields specified in the bundle.  Since these
      considerations involve additional complexity and potential changes to
      <xref target='RFC5050'/> itself, they are only noted in this document as future considerations
      and not treated normatively for the protocol. </t>
    </section>

  </section>

</middle>

<back>
    <references title="References">
&rfc4838;
&rfc5050;
&I-D.irtf-dtnrg-bundle-security;
    </references>
</back>

</rfc>

--------------070404090308090808070100--

Date: Mon, 26 Jul 2010 13:54:01 +0200
From: Anders Lindgren <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] ExtremeCom 2010 - The Himalayan Expedition (Call for Participations)

Apologies if you receive multiple copies.
Please note that the workshop is held the week after Sigcomm 2010
(which is in Delhi), so if you plan to attend Sigcomm, the extra
travel expenses for ExtremeCom will be small.

Anders Lindgren and Pan Hui

--------

Call for Papers and Demos for The 2nd Extreme Workshop on
Communication -
The Himalayan Expedition (ExtremeCom 2010)

September 4-10, 2010

                           http://www.extremecom.org

                   --In Cooperation with ACM SIGCOMM

The Extreme Workshop on Communication (ExtremeCom) intends to bring
together researchers and practitioners in areas related to challenged
networks in order to gain experience and insight into the challenges
that such environments pose for the network and the users. Such
networks include delay and disruption tolerant networks, sparse sensor
networks, power-efficient networking, as well as other networking
paradigms for rural and remote areas.

We aim to do this through a real-life experience in the Indian
Himalayan region. Dharamsala, where the workshop will take place, is a
well-frequented and loved destination for visitors. This mountainous
town presents a unique mix of cultures and spiritual traditions and is
also a starting point to a number of spectacular trekking trails.
Dharamsala is also the place where Dharamsala Community Network came
to life in February 2005, following the deregulation of WiFi for
outdoor use in India.  Built and operated by AirJaldi, a social
enterprise, the network grew from 8 campuses in 2005 to over 2,000
computers spread in campuses, offices and homes within a radius of
70Km. in and around Dharamsala.  AirJaldi is building additional
networks in other rural locations in India.
The ExtremeCom 2010 workshop is planned around AirJaldi’s Dharamsala
network’s locations and facilities, thereby giving participants a
great opportunity to be involved in a real-life network deployment.

The workshop will start with a four-day field trip into the mountain
regions around Dharamsala. During this time, participants will be
given the opportunity to hike along the trails in the mountains, visit
local villages and Tibetan settlements and meet the local population
and users of the network.  The combination of trekking and meetings
will give participants a better idea of both the technical and user
requirements of the network, as well as provide opportunities for
informal research discussions between the participants.

Participants who have their own solutions for scenarios like this will
also, to as great an extent as possible, be encouraged to test and
demonstrate it within this environment. (We are currently planning the
mountain-based part of the workshop and some details are subject to
change.) During the field trip, participants will be given the chance
to work with AirJaldi to set up more relays, for example in schools
along the hiking trail (details to be provided at a later stage).

Upon reaching the end of the hike, we will conduct a two-day technical
session in a more traditional conference venue with paper
presentations and demos. The focus will still be on informal research
discussions, with the hope that the recent field experience they have
gone through together will give participants the ability to view and
discuss the topics presented with additional insights.

Date: Mon, 26 Jul 2010 10:54:10 +0100
From: Elwyn Davies <[email-masked]>
To: DTN <[email-masked]>
Cc: Peter Lovell <[email-masked]>
Subject: [dtn-interest] Updated eContent fields in BSP

Hi,

Looking through the updates to the eContent field in -16 of the BSP, I 
was unclear how the values of the eContent field were going to be derived.

In Sections 4.1, 4.3 and 4.4 the value is to be "the encrypted BEK that
   protects the payload and certain security blocks of the bundle."  
*How* is this to be encrypted?
I guess this is tied back to the options in RFC5652 section 6, but I 
think it would be useful to explicitly say this, or if not specify how 
it is encrypted.

In Section 4.2, the digest algorithm used is presumably specified in the 
SignedData structure as per RFC 5652 section 5.1.  Does this all imply 
that the  'integrity signature' field specified in  Section 2.6 of the 
draft contains a SignedData structure?

Regards,
Elwyn

Date: Mon, 26 Jul 2010 10:35:29 +0100
From: Elwyn Davies <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Updates for metadata and security drafts

New versions of the metadata block and bundle security protocol have 
been put in the repository.
These versions should make the drafts ready for IRSG approval and 
siubmission to the RFC Editor.

http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-metadata-block-09
Minor editorial fixed (cut-and-paste error in the previous version).

http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-security-16
Two areas updated:
- Sections 4.1, 4.2, 4.3 and 4.4: In each case the usage of the eContent 
field in EncryptedContentInfo has been changed from 'MUST be omitted' to 
specify the usage for the eContent field (different in each case, but 
tied to a key value or signature value).
- Section 9: IANA considerations updated with registry definitions 
inserted as discussed at previous meetings.

Regards,
Elwyn
Document Shepherd.

Date: Mon, 26 Jul 2010 10:13:17 +0100
From: Elwyn Davies <[email-masked]>
To: DTN <[email-masked]>
Cc: N4C Technical discusion <[email-masked]>
Subject: [dtn-interest] Updated version of PRoPHET draft

There is a new version of the PRoPHET draft in the repository.
http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-06

We have made some improvements to the transitivity algorithm in the 
light of experiments in the N4C test beds, and provided means to 
overcome 'the parking lot problem' that has been bugging us for a long 
time.  I will be presenting more details of the improvements at the 
meeting in Maastricht on Friday.

Regards,
Elwyn

pp The authors (Anders Lindgren, Avri Doria, Samo Grasic, and Elwyn Davies).

Date: Sun, 18 Jul 2010 13:55:36 +0200
From: aviana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] IEEE MASS 2010: Call for Participation and Important Dates for Demos CFP

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

==========================================================================
                           CALL FOR PARTICIPATION

                                IEEE MASS 2010
              7th IEEE International Conference on Mobile Ad-hoc
                            and Sensor Systems
                      https://mass2010.soe.ucsc.edu/

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

Co-sponsored by the IEEE Computer Society Technical Commitee on
Distributed Processing and IEEE Computer Society Technical Commitee on
Simulation

==========================================================================

CONFERENCE SITE:
----------------
The 7th IEEE International Conference on Mobile Ad-hoc and Sensor
Systems (IEEE MASS 2010) will be held in San Francisco, California, USA.

SCOPE:
------
Wireless ad-hoc communication has applications in a variety of
environments, such as conferences, hospitals, battlefields and
disaster-recovery/rescue operations, and is also being actively
investigated as an alternative paradigm for Internet connectivity in
both urban and rural areas. Wireless sensor and actuator networks are
also being deployed for enhancing industrial control processes and
supply-chains, and for various forms of environmental monitoring. The
IEEE MASS 2010 aims at addressing advances in research on multi-hop
ad-hoc and sensor networks, covering topics ranging from technology
issues to applications and test-bed development. Please keep checking
the IEEE MASS 2010 web-space for more information and regular updates.

REGISTRATION:
-------------
Registration to IEEE MASS is now available at the conference website.
Early registration ends on September 3rd.

WORKSHOPS:
----------
- The Third Workshop on Mobile Entity Localization and Tracking (MELT)
- The Second Workshop on SCEnarios for Network Evaluation Studies (SCENES)
- The Sixth Workshop on Wireless and Sensor Network Security (WSNS)
- The Fourth Workshop on Enabling Technologies and Standards for
Wireless Mesh Networking (MESHTECH)
- The First BioSense Workshop: Networking and Environmental Sensing meet
Epidemiology and Biology
- The Second International Workshop on Intelligent Vehicular Networks
(InVeNet)

CFP DEMOS – IMPORTANT DATES:
----------------------------
Abstract submission deadline:     30 July 2010
Acceptance notification:          27 August 2010
Camera-ready submission:         10 September 2010
IEEE MASS 2010:                  8-12 November 2010

ORGANIZATION COMMITTEE:
-----------------------

GENERAL CO-CHAIRS
Mario Gerla, University of California, Los Angeles
Katia Obraczka, University of California, Santa Cruz

PROGRAM CO-CHAIRS
Guohong Cao, Pennsylvania State University
Prasant Mohapatra, University of California, Davis

TPC SUB-AREA CHAIRS
- Protocols and Cross-Layer Technologies
Ahmed Helmy, University of Florida

- Systems, and applications
Chenyang Lu, Washington Unviersity in St. Louis

- Algorithms and theory
Dong Xuan, Ohio State University

- Reliability, security and privacy
Radha Poovendran, University of Washington

WORKSHOP CO-CHAIRS
Cedric Westphal, DoCoMo Labs
Christine Pepin, DoCoMo Labs

DEMO CHAIR
Rajeev Koodli, Starent Networks
Marcelo Dias Amorim, LIP 6, Universite' Paris 6

WEB CHAIR
Venkatesh Rajendran, Wionics

FINANCE AND REGISTRATION CHAIR
Zhen Jiang, West Chester University

PUBLICATION CHAIR
Dajin Wang, Montclair State University

PUBLICITY CHAIR
Aline Carneiro Viana, INRIA

LOCAL ARRANGEMENTS CO-CHAIRS
Kumar Viswanath, NTT Labs
Ignacio Solis, PARC

STEERING COMMITTEE CHAIR
Dharma P. Agrawal, University of Cincinnati

CHAIR OF IEEE TC ON DISTRIBUTED PROCESSING
Jie Wu, US National Science Foundation

CHAIR OF IEEE TC ON SIMULATION
Dave Cavalcanti, Phillips Research

Date: Sat, 10 Jul 2010 01:39:04 +0530
From: Aaditeshwar Seth <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Post-doc opening

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Dear all,<br>
    <br>
    We have a joint post-doc opening at National ICT Australia (NICTA)
    and the Department of Computer Science at IIT Delhi, in the area of
    computer networks and distributed systems applied to development.
    The broad project is along technologies to assist social media in
    rural areas, such as through community radio, participatory video,
    voice messaging, etc. Candidates with a background in delay tolerant
    networks, wireless meshes, social networks, or machine learning and
    information retrieval are strongly encouraged to apply. The projects
    will be very hands-on, in close association with groups like Gram
    Vaani (<a class="moz-txt-link-freetext" href="http://gramvaani.org">http://gramvaani.org</a>)
    and Video Volunteers (<a class="moz-txt-link-freetext"
      href="http://www.videovolunteers.org/">http://www.videovolunteers.org/</a>),

    and the ACT4D research group at IIT Delhi (<a
      class="moz-txt-link-freetext"
      href="http://www.cse.iitd.ernet.in/act4d/">http://www.cse.iitd.ernet.in/act4d/</a>).<br>
    <br>
    The researcher will be based out of Australia, but will be able to
    travel frequently between India and Australia, and deploy systems on
    the ground. <br>
    <br>
    People leading the project are Aaditeshwar Seth at IIT Delhi (<a
      class="moz-txt-link-freetext"
      href="http://www.cse.iitd.ernet.in/%7Easeth/">http://www.cse.iitd.ernet.in/~aseth/</a>)
    and Anirban Mahanti at NICTA (<a class="moz-txt-link-freetext"
      href="http://www.nicta.com.au/people/mahantia">http://www.nicta.com.au/people/mahantia</a>).<br>
    <br>
    Interested applicants should send an email to <a
      class="moz-txt-link-abbreviated"
      href="mailto:[email-masked]">[email-masked]</a><br>
    <br>
    regards<br>
    Aaditeshwar<br>
  </body>
</html>

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>, dtn interest <[email-masked]>
Date: Thu, 08 Jul 2010 19:42:51 -0400
Subject: Re: [dtn-interest] Chair affiliation

On Fri, Jul 9, 2010, Stephen Farrell <[email-masked]> wrote:

>I'll be spending the other
>20% doing fun start-up type stuff with Tolerant Networks
>Ltd. [1]

Certainly looks like fun stuff !!

Cheers.....Peter

Date: Fri, 09 Jul 2010 00:15:55 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Chair affiliation

Hi,

There was a discussion on the IETF wg chairs list last year
that concluded it'd be good for chairs to be transparent
about their affiliation. (That has nothing to do with DTNRG
really, but since I've just sent the same mail to the IETF
WG I chair...)

So: Until recently (April) I was working 50:50 for Trinity
College Dublin (TCD) and NewBay Software. Since then I've got
some more research money and so I've quit NewBay and am
now working 80% of my time in TCD. I'll be spending the other
20% doing fun start-up type stuff with Tolerant Networks
Ltd. [1]

Stephen.

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

Date: Tue, 6 Jul 2010 11:06:12 +0200
From: Anders Lindgren <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] ExtremeCom 2010 Student Travel Grants

(Apologies for any duplicates received of this message)

Student travel grant for the 2nd Extreme Workshop on Communication -
The Himalayan Expedition (ExtremeCom 2010)
http://extremecom.org/

We are please to announce that we have been able to allocate some
funds to provide travel grants for students wishing to attend
ExtremeCom 2010, but lacking funds to do so otherwise.
Priority for the travel grants will be given to students who do not
have a paper accepted at the workshop.

The ExtremeCom workshop provides a great opportunity for students of
DTNs, ICT4D, networks for challenged areas, and related areas to
discuss these topics with other researchers and also experience the
target environments for these types of systems in real life.
ExtremeCom 2010 will begin with a multi-day hike through the mountains
of the Dharamsala region of India, where the AirJaldi.org network is
deployed. This is followed by a technical workshop where research
papers and demos are presented.

The travel grant will cover the full registration fee for the
workshop, which also includes all food during the workshop as well as
accomodation during the hiking part of the workshop.

To apply for the grant, please send an email to [email-masked] and
[email-masked] containing:
* Name, university affiliation, and student status (Ph.D/M.Sc.
student, and how far progressed you are)
* Motivation to why you would benefit from attending the workshop
* Letter of recommendation from supervisor

Successful applicants should submit a short report on their experience
from the workshop within one month of returning back home.

Please submit your application AT THE LATEST on July 18, but please
note that we reserve the right to process applications as they arrive
(in order to give applicants quick answers and make it easier to book
cheap flight tickets), so submit your applications as soon as
possible.

Hoping to see you in Dharamsala in September!

/Anders and Ben

From: Prosenjit Dhole <[email-masked]>
Date: Mon, 5 Jul 2010 13:44:59 +0530
To: [email-masked], DTNRG <[email-masked]>, DTNRG <[email-masked]>, [email-masked]
Subject: [dtn-interest] Help required regarding bluetooth communication with daemon

--000e0cd1a52e8ffccf048a9f89aa
Content-Type: text/plain; charset=ISO-8859-1

Hi ,

I was trying to write a daemon counter part for mobiles in J2ME .
Can anyone please help me with some code snippet showing the daemon
discovery part
via bluetooth.  I am stuck with the correct parameter values of
searchServices ( such as the correct UUID, attribute list etc).

Thanks in advance

-- Prosenjit

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

<div class=3D"gmail_quote">Hi ,<br><br>I was trying to write a daemon count=
er part for mobiles in=20
J2ME .<br>Can anyone please help me with some code snippet showing the=20
daemon discovery part <br>via bluetooth.=A0 I am stuck with the correct=20
parameter values of searchServices ( such as the correct UUID, attribute
 list etc).<br>

<br><br>Thanks in advance <br><font color=3D"#888888"><font color=3D"#88888=
8"><br>-- Prosenjit <br></font>
</font></div><br>

--000e0cd1a52e8ffccf048a9f89aa--

From: Prosenjit Dhole <[email-masked]>
Date: Mon, 5 Jul 2010 13:22:03 +0530
To: DTNRG <[email-masked]>, DTNRG <[email-masked]>
Subject: [dtn-interest] Help required regarding bluetooth communication with daemon

--000e0cd330208c9cf7048a9f373e
Content-Type: text/plain; charset=ISO-8859-1

Hi ,

I was trying to write a daemon counter part for mobiles in J2ME .
Can anyone please help me with some code snippet showing the daemon
discovery part
via bluetooth.  I am stuck with the correct parameter values of
searchServices ( such as the correct UUID, attribute list etc).

Thanks in advance

-- Prosenjit

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

Hi ,<br><br>I was trying to write a daemon counter part for mobiles in=20
J2ME .<br>Can anyone please help me with some code snippet showing the=20
daemon discovery part <br>via bluetooth.=A0 I am stuck with the correct=20
parameter values of searchServices ( such as the correct UUID, attribute
 list etc).<br>

<br><br>Thanks in advance <br><font color=3D"#888888"><br>-- Prosenjit <br>=
</font>

--000e0cd330208c9cf7048a9f373e--