Subject: Re: [dtn-interest] Reactive Fragmentation
From: Michael Demmer <[email-masked]>
To: Matthew Robert Seligman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Sun, 30 Oct 2005 14:09:47 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

In my implementation of a TCP convergence layer, acks are sent
periodically on the connection as the receiver consumes chunks of
payload.

-mike

> Jeff,
> 
> Thanks for the information. 
> 
> When are the watermark acks sent by the recipient to the sender?  Is it 
> a recurring transmission sent every so often or is it sent after the 
> link returns to service after an interruption?
> 
> Thanks,
> - Matt
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Sun, 30 Oct 2005 10:17:19 -0500 (EST)
From: Matthew Robert Seligman <[email-masked]>
Subject: Re: [dtn-interest] Reactive Fragmentation
To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Jeff,

Thanks for the information. 

When are the watermark acks sent by the recipient to the sender?  Is it 
a recurring transmission sent every so often or is it sent after the 
link returns to service after an interruption?

Thanks,
- Matt

Cc: [email-masked]
From: Evan Jones <[email-masked]>
Subject: Re: [dtn-interest] Reactive Fragmentation
Date: Sat, 29 Oct 2005 10:26:42 -0400
To: Matthew Robert Seligman <[email-masked]>
Sender: [email-masked]

On Oct 27, 2005, at 11:17, Matthew Robert Seligman wrote:
> Several papers and the bundle protocol documentation discuss the
> concept of reactive fragmentation, but I cannot find information about
> how it will actually work in operation.

Well, since no one has responded to this message, I'll take a stab at 
it. I'm not much of an expert on this topic, but I think the answer is 
that it isn't well defined how exactly it would work. To answer your 
question, the concept is that when the link comes back up, the sender 
transmits the portion that was not received during the previous 
attempt.

You are correct: Some mechanism at the convergence layer need to 
indicate which byte ranges have been successfully received by the other 
end. At a lower layer, this likely requires byte range 
acknowledgements. I also imagine that the final receiver will need to 
be smart enough to remove overlapping segments that get received and 
recover the original bundle.

I hope that I haven't made too many mistakes, and that this helps.

Evan Jones

--
Evan Jones
http://evanjones.ca/

Content-class: urn:content-classes:message
Date: Fri, 28 Oct 2005 15:39:21 -0700
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] StudyHall project at Princeton
Sender: [email-masked]

Some of you may have heard of Randy Wang's 'postman-net' project at
Princeton.  In the last year, that has expanded considerably into
education in India (I just heard his talk).  Here is a link, that I
think some of you may find interesting:

www.cs.princeton.edu/~rywang/distance

- Kevin

Date: Thu, 27 Oct 2005 11:17:21 -0400 (EDT)
From: Matthew Robert Seligman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-interest] Reactive Fragmentation
Sender: [email-masked]

Several papers and the bundle protocol documentation discuss the 
concept of reactive fragmentation, but I cannot find information about 
how it will actually work in operation.  

When the receiver becomes available again, either due to free storage 
or a link returns to service,  what does the sender transmit to the 
receiver, the entire bundle or only the portion not received by the 
receiver?  If it's the latter, how and when does the sender receive 
information about how much of the bundle was correctly received at the 
receiver?

On a more general note, does a sender receive exactly one ACK per 
bundle it sends or does it receive ACKs that acknowledge a portion of 
the bundle?

Thanks in advance for the information.
- Matt

Date: Wed, 19 Oct 2005 16:20:17 -0400
From: Manikantan Ramadas <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] Re: Acknowledge.Request (formerly Thoughts on the current Bundling draft)
Sender: [email-masked]

--GID0FwUMdk1T2AWN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 19, 2005 at 12:27:43PM -0700, Michael Demmer wrote:
>=20
> >   What bothered me here was that BPA is now going to generate something=
 for
> > an application without any means of checking the validity of the parame=
ters
> > given. The way we have it specified currently, it seems to me like, any
> > DTN application which need not even have registered with the BPA with
> > a REGISTER.REQUEST for receiving data could potentially make an
> > ACKNOWLEDGE.REQUEST maliciously (just for DoS-ing the channel say) and =
that
> > with no accountability whatsoever.
> >=20
> >   OTOH, if the ACKNOWLEDGE.REQUEST carried the Registration Token too, =
the
> > BPA could at the least verify that this request is being made by an
> > application known to it, and could also verify that the
> > bundle-creation-timestamp references a bundle that it indeed recently
> > delivered on the registration. It is this lack of accountability at the=
 BPA,
> > that seems like an invitation for DoS, as opposed to DoS-ing with
> > TRANSMIT.REQUEST in which case atleast the BPA can track the transmissi=
ons
> > with the Transmission.Tokens it has seen in the past.
>=20
> But there's nothing to stop a BPA from doing at least the 2nd part of
> your DoS prevention proposal -- that is to ensure the ACK is being
> generated in response to a recently delivered bundle identified by
> <source eid, creation timestamp>. A malicious app would have a hard
> time guessing this information.
>=20
> It seems like all you want to do is add a registration token to the
> mix.

  Because that seems like the easiest way for the BPA to verify the identity
of the application making the ACK request.

> But that would prevent an APP from registering, getting a bundle,
> unregistering, processing the bundle, then ack'ing the bundle. Given
> that the intent of the ACK is to accomodate a potentially non-trivial
> amount of time between delivery and processing, this seems like a
> viable scenario, and the additional DoS prevention security doesn't
> seem worth it.=20

  The difference would be in looking up just the bundle creation timestamps
received for a specific registration (to verify that the bundle creation
timestamp is legitimate) as opposed to checking with all the bundle creation
timestamps ever received.

  Further, why hurry in unregistering if you expect to be generating an ACK
request? Why not register, get the bundle, process the bundle, ack it
whenever, and unregister in the end.=20
=20
> >   Thanks for that. I have a feel for the motivation now; but I don't
> > think I grasp your example fully. So, if you have a layout such as below
> >=20
> > =20
> >   Source App. <=3D=3D=3D>   Sender App.         Receiver App. <=3D=3D=
=3D>  Destn. App.
> >                       ----------          ------------
> >                       DTN proxy  <=3D=3D=3D>    DTN proxy =20
> >  =20
> >   =20
> >   you are saying that an application running over the Receiver DTN proxy
> > (say SMTP) would generate an ACKNOWLEDGE request to the local BPA after
> > sending the mail to the actual Destination SMTP application. Is this
> > acknowledgment for the SMTP running on the Sender DTN proxy or the Sour=
ce,=20
> > I don't follow.=20
>=20
> It's for the sender DTN proxy. The source app may have left the scene,
> and has entrusted the proxy with delivering its bundles. Envision the
> source side proxy as one that has no knowledge of the actual app
> protocol, it just gets a bundle from the source app, that's
> appropriately destined for the receiver proxy, but it wants to know
> when the destination app gets it.
>
  Okay. Except that I would be happier if we kept BPA in the loop and had a
Delivery Option in Section 2.4.5 for "Report when bundle processed" so that
the BPA at the receiver side DTN proxy would know to expect an ACK request
at a later time from the application. This way, the fact that an ACK request
is expected could also be communicated to the App. along with bundle delive=
ry.

- Mani.

--=20
"Asathomaa Sath-gamaya" : Lead us from untruth towards Truth.
"Thamasomaa Jyothir-gamaya" : Lead us from darkness towards Light.
"Mrithyomaa Amrutham-gamaya" : Lead us from death towards eternal Life.
                              -- Hymn from the Brihadaranyaka Upanishad
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--GID0FwUMdk1T2AWN
Content-Type: application/pgp-signature
Content-Disposition: inline

--GID0FwUMdk1T2AWN--

Date: Wed, 19 Oct 2005 12:27:43 -0700
From: Michael Demmer <[email-masked]>
To: Manikantan Ramadas <[email-masked]>
Cc: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the current Bundling draft
Mail-Followup-To: Manikantan Ramadas <[email-masked]>, DTNRG <[email-masked]>
Sender: [email-masked]

>   What bothered me here was that BPA is now going to generate something for
> an application without any means of checking the validity of the parameters
> given. The way we have it specified currently, it seems to me like, any
> DTN application which need not even have registered with the BPA with
> a REGISTER.REQUEST for receiving data could potentially make an
> ACKNOWLEDGE.REQUEST maliciously (just for DoS-ing the channel say) and that
> with no accountability whatsoever.
> 
>   OTOH, if the ACKNOWLEDGE.REQUEST carried the Registration Token too, the
> BPA could at the least verify that this request is being made by an
> application known to it, and could also verify that the
> bundle-creation-timestamp references a bundle that it indeed recently
> delivered on the registration. It is this lack of accountability at the BPA,
> that seems like an invitation for DoS, as opposed to DoS-ing with
> TRANSMIT.REQUEST in which case atleast the BPA can track the transmissions
> with the Transmission.Tokens it has seen in the past.

But there's nothing to stop a BPA from doing at least the 2nd part of
your DoS prevention proposal -- that is to ensure the ACK is being
generated in response to a recently delivered bundle identified by
<source eid, creation timestamp>. A malicious app would have a hard
time guessing this information.

It seems like all you want to do is add a registration token to the
mix. But that would prevent an APP from registering, getting a bundle,
unregistering, processing the bundle, then ack'ing the bundle. Given
that the intent of the ACK is to accomodate a potentially non-trivial
amount of time between delivery and processing, this seems like a
viable scenario, and the additional DoS prevention security doesn't
seem worth it. 

>   Thanks for that. I have a feel for the motivation now; but I don't
> think I grasp your example fully. So, if you have a layout such as below
> 
>  
>   Source App. <===>   Sender App.         Receiver App. <===>  Destn. App.
>                       ----------          ------------
>                       DTN proxy  <===>    DTN proxy  
>   
>    
>   you are saying that an application running over the Receiver DTN proxy
> (say SMTP) would generate an ACKNOWLEDGE request to the local BPA after
> sending the mail to the actual Destination SMTP application. Is this
> acknowledgment for the SMTP running on the Sender DTN proxy or the Source, 
> I don't follow. 

It's for the sender DTN proxy. The source app may have left the scene,
and has entrusted the proxy with delivering its bundles. Envision the
source side proxy as one that has no knowledge of the actual app
protocol, it just gets a bundle from the source app, that's
appropriately destined for the receiver proxy, but it wants to know
when the destination app gets it.

-m

Date: Wed, 19 Oct 2005 14:58:31 -0400
From: Manikantan Ramadas <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the current Bundling draft
Sender: [email-masked]

--xHFwDpU9dbj6ez1V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Mike,

On Tue, Oct 18, 2005 at 12:10:33PM -0700, Michael Demmer wrote:
>=20
> > ...
>=20
> I fail to understand your argument here. You do not need a
> registration in order to transmit, and never have. The transmission
> token is simply an application-specified value to map transmit
> requests to transmission indications, i.e. just the way to get the
> success/failure of the transmission.
>=20

  Alright, I understand it much clearly now that the registration token
needs to be kept and used only by a receiving application.

> In my mind, the information provided in the ACKNOWLEDGE.REQUEST is
> simply a reduced set of the information given to TRANSMIT.REQUEST,
> where the other values are specified by default.
>=20

  Sure.
  =20
> > 1) The sender has no way of seeking this as a delivery option in Sec
> > 2.4.5 So, it seems to me that all Acknowledgment Administrative
> > records are gratuitous. That seems like an invitation for DoS to me.
>=20
> How so? All the ACKNOWLEDGE.REQUEST is provide a consistent mechanism
> for applications to generate status reports in a well-specified
> manner. I fail to see how this is more likely to generate DoS than any
> other bundle transmission, so perhaps you could elaborate.
>=20

  What bothered me here was that BPA is now going to generate something for
an application without any means of checking the validity of the parameters
given. The way we have it specified currently, it seems to me like, any
DTN application which need not even have registered with the BPA with
a REGISTER.REQUEST for receiving data could potentially make an
ACKNOWLEDGE.REQUEST maliciously (just for DoS-ing the channel say) and that
with no accountability whatsoever.

  OTOH, if the ACKNOWLEDGE.REQUEST carried the Registration Token too, the
BPA could at the least verify that this request is being made by an
application known to it, and could also verify that the
bundle-creation-timestamp references a bundle that it indeed recently
delivered on the registration. It is this lack of accountability at the BPA,
that seems like an invitation for DoS, as opposed to DoS-ing with
TRANSMIT.REQUEST in which case atleast the BPA can track the transmissions
with the Transmission.Tokens it has seen in the past.

  Now, I know that various REQUESTs have been specified as primitives and
not in the level of detail of an API specification, but if we want to
make the BPA do some Application-Layer work, at the least we need to provide
avenues for it to keep track of the Applications for which it is doing so.
Don't you think?

> > ...
>=20
> Well, the proposed scenario which caused us to come up with this idea
> was the following (Kevin, please correct me if I'm missing anything):
>=20
> Suppose you're running a pair of DTN proxies, say to forward email and
> web blog posts across a DTN network. With this mechanism, the
> destination application would generate an ACKNOWLEDGE.REQUEST when it
> has successfully forwarded the payload in an application-specific
> manner to the SMTP or blog destination. The sender-side proxy could
> have application-agnostic code that waits for the acknowledgement
> status reports to flow back to the sender. It therefore doesn't need
> specific code to handle acks from SMTP, acks from Jabber, etc, etc.
>=20

  Thanks for that. I have a feel for the motivation now; but I don't
think I grasp your example fully. So, if you have a layout such as below

=20
  Source App. <=3D=3D=3D>   Sender App.         Receiver App. <=3D=3D=3D>  =
Destn. App.
                      ----------          ------------
                      DTN proxy  <=3D=3D=3D>    DTN proxy =20
 =20
  =20
  you are saying that an application running over the Receiver DTN proxy
(say SMTP) would generate an ACKNOWLEDGE request to the local BPA after
sending the mail to the actual Destination SMTP application. Is this
acknowledgment for the SMTP running on the Sender DTN proxy or the Source,=
=20
I don't follow. Because if it is for the Source Application, it seems
redundant since it would  get the SMTP application ACK from the Destination
SMTP as a separate bundle any ways because the Destination Application would
send an SMTP ACK which would be received by the SMTP agent running on the
Receiver DTN proxy and a Transmission.Request would be made for it. I must
be missing something here.

- Mani.

--=20
"Asathomaa Sath-gamaya" : Lead us from untruth towards Truth.
"Thamasomaa Jyothir-gamaya" : Lead us from darkness towards Light.
"Mrithyomaa Amrutham-gamaya" : Lead us from death towards eternal Life.
                              -- Hymn from the Brihadaranyaka Upanishad
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--xHFwDpU9dbj6ez1V
Content-Type: application/pgp-signature
Content-Disposition: inline

--xHFwDpU9dbj6ez1V--

Date: Tue, 18 Oct 2005 12:10:33 -0700
From: Michael Demmer <[email-masked]>
To: Manikantan Ramadas <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the current Bundling draft
Mail-Followup-To: Manikantan Ramadas <[email-masked]>, Scott Burleigh <[email-masked]>, DTNRG <[email-masked]>
Sender: [email-masked]

>   I agree that it is an architecture question but it is also an inherent
> part of the Bundling protocol design, right. What makes it worse in the way
> it is specified right now is that the application has no accountability to
> the BPA for it to generate an Acknowledgement administrative record. For
> example, the primitive in Sec 2.5.9 does not take a registration token even.
> So any application could make an Acknowledge.Request
> accidentally/maliciously for another. OTOH, for an application to
> generate application-layer acks, it needs to have acquired a registration
> token and a transmission token; So it is in theory more overt and easily
> trackable by the BPA.

I fail to understand your argument here. You do not need a
registration in order to transmit, and never have. The transmission
token is simply an application-specified value to map transmit
requests to transmission indications, i.e. just the way to get the
success/failure of the transmission.

In my mind, the information provided in the ACKNOWLEDGE.REQUEST is
simply a reduced set of the information given to TRANSMIT.REQUEST,
where the other values are specified by default.

> 1) The sender has no way of seeking this as a delivery option in Sec
> 2.4.5 So, it seems to me that all Acknowledgment Administrative
> records are gratuitous. That seems like an invitation for DoS to me.

How so? All the ACKNOWLEDGE.REQUEST is provide a consistent mechanism
for applications to generate status reports in a well-specified
manner. I fail to see how this is more likely to generate DoS than any
other bundle transmission, so perhaps you could elaborate.

> 2) I would assume that having (a) "report when application processed
> the bundle" along with (b) "report when bundle was delivered to the
> application" implies that there are environments where it is
> valuable to know the non-negligible time that may elapse between
> when the application was delivered the bundle, and when the
> application processed the same. Under such environments, my gut
> feeling says that an even more sophisticated report about
> application processing the bundle may be valuable (besides just the
> time when processing completed). This again argues for leaving this
> as an application ACK which could be as sophisticated as the
> application protocol wishes it to be. Just out of curiosity, I am
> wondering in what DTN environment examples would (a) be valuable
> along with the presence of (b).

Well, the proposed scenario which caused us to come up with this idea
was the following (Kevin, please correct me if I'm missing anything):

Suppose you're running a pair of DTN proxies, say to forward email and
web blog posts across a DTN network. With this mechanism, the
destination application would generate an ACKNOWLEDGE.REQUEST when it
has successfully forwarded the payload in an application-specific
manner to the SMTP or blog destination. The sender-side proxy could
have application-agnostic code that waits for the acknowledgement
status reports to flow back to the sender. It therefore doesn't need
specific code to handle acks from SMTP, acks from Jabber, etc, etc.

Now from a strict layering perspective, an alternative design would be
to keep the generating and parsing functionality in the application,
but to specify a standard bundle payload format for these acks. Our
intuition was that providing this mechanism as a service to
applications reduces the burden on implementation, and since the BPA
already needs to have support for generating and parsing other kinds
of status reports, this additional feature provides some benefit to
applications at little added cost.

-mike

Date: Tue, 18 Oct 2005 14:47:13 -0400
From: Manikantan Ramadas <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the current Bundling draft
Sender: [email-masked]

--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Scott,

> >>>The key advantage is that the BPA need not keep state of an erstwhile=
=20
> >>>session just
> >>>in case it might get an Acknowledge.Request for that session in the=20
> >>>future.
> >>>    =20
> >>>
> >>But it needn't do that anyway; the parameters to the Acknowledge.reques=
t=20
> >>provide all the information needed to issue that status report (I think=
).
> >>  =20
> >>
> > Yeah, the Acknowledge.Request does give the BPA all it needs.
> > But I was thinking that the BPA would atleast want to do some sanity
> >checking to make sure that the bundle creation timestamp refers to a bun=
dle
> >it has seen in the past to prevent an Application Agent (which is totally
> >under an application control as you said)=20
> >from generating arbitrary Acknowledge.Request
> >parameters. It could be a security-problem in some sense if such a sanity
> >check was not made. See, these are the places where the layering violati=
on
> >comes to bite you.
> >=20
> >
> But if the application generated application-layer acknowledgements --=20
> which would, like acknowledgement status reports, be distinct bundles --=
=20
> wouldn't you have the same situation?  What makes this worse?
>=20

  I agree that it is an architecture question but it is also an inherent
part of the Bundling protocol design, right. What makes it worse in the way
it is specified right now is that the application has no accountability to
the BPA for it to generate an Acknowledgement administrative record. For
example, the primitive in Sec 2.5.9 does not take a registration token even.
So any application could make an Acknowledge.Request
accidentally/maliciously for another. OTOH, for an application to
generate application-layer acks, it needs to have acquired a registration
token and a transmission token; So it is in theory more overt and easily
trackable by the BPA.

  Some other reasons why I don't like the BPA generating acknowledgment
administrative records are that=20

  1) The sender has no way of seeking this as a delivery option in Sec 2.4.5
So, it seems to me that all Acknowledgment Administrative records are
gratuitous. That seems like an invitation for DoS to me.

  2) I would assume that having (a) "report when application processed the
bundle" along with (b) "report when bundle was delivered to the application"
implies that there are environments where it is valuable to know the
non-negligible time that may elapse between when the application was
delivered the bundle, and when the application processed the same. Under
such environments, my gut feeling says that an even more sophisticated
report about application processing the bundle may be valuable (besides just
the time when processing completed). This again argues for leaving this
as an application ACK which could be as sophisticated as the application
protocol wishes it to be. Just out of curiosity, I am wondering in what
DTN environment examples would (a) be valuable along with the presence of (=
b).

I would also be interested in hearing what other folks in the mailing list
feel about this.

- Mani.

--=20
"Asathomaa Sath-gamaya" : Lead us from untruth to Truth.
"Thamasomaa Jyothir-gamaya" : Lead us from darkness to Light.
"Mrithyomaa Amrutham-gamaya" : Lead us from death to eternal Life.
                              -- Brihadaranyaka Upanishad
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--WIyZ46R2i8wDzkSu
Content-Type: application/pgp-signature
Content-Disposition: inline

--WIyZ46R2i8wDzkSu--

Date: Mon, 17 Oct 2005 09:19:37 -0700
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the current Bundling draft
Sender: [email-masked]

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

Manikantan Ramadas wrote:

>>>o Section 2.4.6 : Lifespan - It is specified as the length of time 
>>>following
>>>the initial transmission of the bundle. But lifespan is actually the
>>>time following the creation time of the bundle, as mentioned everywhere 
>>>else
>>>in the document. Since creation time need not always be the same as the
>>>initial transmission time, this needs to be fixed accordingly.
>>>
>>>
>>>      
>>>
>>But bundle creation time and initial transmission time are the same 
>>time.  See 2.4.11 and 4.2.
>>
>>    
>>
>  In neither of these two sections do I find a reference to an "initial
>transmission time". Bundle creation time is specified clearly as the time at
>which the Transmit.Request was received at the BPA. But "initial
>transmission time" means to me as the time at which actual transmission of
>the bundle happens, which may be later in time if the bundle sat there with
>a Dispatch Pending / Forward Pending retention constraint waiting for a link
>to show up. Thats why I request a more accurate use of terminology in the
>definition of what a Lifespan is.
>  
>
But that's not what "transmission" means in this document.  
"Transmission" is defined in general on page 8 and in detail in section 
4.2 (see the last sentence of Step 1), and I don't think there's any 
inconsistency in the way the term is used.

However, the change you propose certainly does no harm and isn't a lot 
of work, so okay.

>>>o Section 2.5.1 TRANSMIT.REQUEST and 2.5.3 REGISTER.REQUEST:
>>>
>>>Do we assume the AA to choose our Registration Token and Transmission
>>>Token, and not the application itself directly? I am just worried about 
>>>some
>>>one in the middle (besides the application itself) guaranteeing that these
>>>tokens are unique at the BPA.
>>>      
>>>
>>No problem, the application agent *is* "the application itself".  The 
>>"agent" part of the name "application agent" doesn't mean that it 
>>operates on behalf of something else, it just means that it operates (as 
>>in a chemical "active agent").
>>    
>>
>So, my bigger question here was, why was this approach taken instead of
>letting the BPA to return a Registration Token / Transmission Token? Similar
>to a socket() call that returns you a socket-descriptor instead of asking
>you to choose your own socket-descriptor. What if two different AA's chose
>the same Regitration Token "100", then you have to give back a
>TRANSMITERROR.INDICATION or some form of REGISTRATIONERROR.INDICATION to the
>second guy. After all the application can live with a completely opaque
>Registration / Transmission token as long as it is meaningful and unique at
>the BPA, right?
>
But this is an abstract service specification, not an API for a 
particular language, so there isn't any notion of "returning" anything; 
that's why this approach was taken.  In an actual implementation you can 
make this happen any way you like, so long as the application always has 
some handle of some sort by which it can cancel a transmission.

>>>o Section 3.5
>>>
>>>Why even make this artificial 1023 byte limit on SSP's and scheme names?
>>>      
>>>
>>Because the offsets are 16-bit integers and we want to have room for 64 
>>different strings.
>>    
>>
>>>Why constrain the endpoint ID references to 16 bit quantities when you can
>>>make them both SDNV's?
>>>      
>>>
>>Because making them SDNVs would introduce additional parsing complexity 
>>without significant offsetting benefit; 1023 bytes per string is already 
>>long enough.  (Maybe too long.)
>>    
>>
>But SDNVs could lead to smaller bundle header sizes, especially when the
>Dictionary is rather small (so that most of the SDNV fields are one octet
>long). But I guess the goal is to aid in quicker parsing rather than
>header-size optimization here.
>
That's right; it's a trade-off, and on this particular issue we came 
down on the side of time efficiency rather than space efficiency.

>>>o Section 4.10.1, Page 36, towards the end of the first para.
>>>
>>>After saying that we may be appending in new entries into the dictionary,
>>>also add that we would be removing any unnecessary entries present in the
>>>dictionary, perhaps?
>>>      
>>>
>>We're not requiring that an implementation do this, as it is non-trivial 
>>and of unclear utility.  But we're also not prohibiting it, in the event 
>>that some implementor gets ambitious.  Since it's in the realm of things 
>>that the implementation *may* do, I'd prefer to leave it out.
>>    
>>
>IMHO, its probably worthwhile to put a single sentence in there to say
>that Implementations MAY do this (so as to make the implementers atleast
>ponder over this); Saying nothing at all about this might cause an
>implementer to not even consider it. In bandwidth constrained environments,
>especially when the MTU size is small, an implementer may have more
>motivation for making sure that he is not shipping any stale data in his
>dictionary (especially when contacts are infrequent and the BPA has all the
>time to optimize its bundle-sizes), don't you think?
>  
>
Okay.

>>>o Section 5.1.1 Bundle Status Reports : Time of Acknowledgement
>>>
>>>This could be okay, except that this seems like a
>>>layering violation to me now. Why should the bundling protocol do the
>>>business of informing the sender when the application finished processing
>>>the data. I think that this would be left best for the application protocol
>>>(if any) operating over the bundling protocol to do; For example, the
>>>application protocol may choose to generate an application-level ACK (which
>>>appears as a separate bundle) for transmission to the source.
>>>      
>>>
>>Yep, we had this discussion; the text in the spec is where it ended up.  
>>I think it can be argued that the bundle protocol is just providing a 
>>little additional service to the application here, much as the Payload 
>>Security Header in the security protocol is a little additional service 
>>to the application.  Not really mandatory, and arguably not the business 
>>of this protocol, but I don't see where it does a lot of harm.
>>    
>>
>>>The key advantage is that the BPA need not keep state of an erstwhile 
>>>session just
>>>in case it might get an Acknowledge.Request for that session in the future.
>>>      
>>>
>>But it needn't do that anyway; the parameters to the Acknowledge.request 
>>provide all the information needed to issue that status report (I think).
>>    
>>
>  Yeah, the Acknowledge.Request does give the BPA all it needs.
>  But I was thinking that the BPA would atleast want to do some sanity
>checking to make sure that the bundle creation timestamp refers to a bundle
>it has seen in the past to prevent an Application Agent (which is totally
>under an application control as you said) 
>from generating arbitrary Acknowledge.Request
>parameters. It could be a security-problem in some sense if such a sanity
>check was not made. See, these are the places where the layering violation
>comes to bite you.
>  
>
But if the application generated application-layer acknowledgements -- 
which would, like acknowledgement status reports, be distinct bundles -- 
wouldn't you have the same situation?  What makes this worse?

I think this is really an architectural issue rather than a protocol 
specification issue, so if you want to pursue it I would propose that 
you start a new thread, which I will happily leave in the hands of Kevin 
and Mike.

Scott

--------------060003010607020902080303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Manikantan Ramadas wrote:
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">o Section 2.4.6 : Lifespan - It is specified as the length of time 
following
the initial transmission of the bundle. But lifespan is actually the
time following the creation time of the bundle, as mentioned everywhere 
else
in the document. Since creation time need not always be the same as the
initial transmission time, this needs to be fixed accordingly.

      </pre>
    </blockquote>
    <pre wrap="">But bundle creation time and initial transmission time are the same 
time.  See 2.4.11 and 4.2.

    </pre>
  </blockquote>
  <pre wrap=""><!---->  In neither of these two sections do I find a reference to an "initial
transmission time". Bundle creation time is specified clearly as the time at
which the Transmit.Request was received at the BPA. But "initial
transmission time" means to me as the time at which actual transmission of
the bundle happens, which may be later in time if the bundle sat there with
a Dispatch Pending / Forward Pending retention constraint waiting for a link
to show up. Thats why I request a more accurate use of terminology in the
definition of what a Lifespan is.
  </pre>
</blockquote>
But that's not what "transmission" means in this document.&nbsp;
"Transmission" is defined in general on page 8 and in detail in section
4.2 (see the last sentence of Step 1), and I don't think there's any
inconsistency in the way the term is used.<br>
<br>
However, the change you propose certainly does no harm and isn't a lot
of work, so okay.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">o Section 2.5.1 TRANSMIT.REQUEST and 2.5.3 REGISTER.REQUEST:

Do we assume the AA to choose our Registration Token and Transmission
Token, and not the application itself directly? I am just worried about 
some
one in the middle (besides the application itself) guaranteeing that these
tokens are unique at the BPA.
      </pre>
    </blockquote>
    <pre wrap="">No problem, the application agent *is* "the application itself".  The 
"agent" part of the name "application agent" doesn't mean that it 
operates on behalf of something else, it just means that it operates (as 
in a chemical "active agent").
    </pre>
  </blockquote>
  <pre wrap=""><!---->So, my bigger question here was, why was this approach taken instead of
letting the BPA to return a Registration Token / Transmission Token? Similar
to a socket() call that returns you a socket-descriptor instead of asking
you to choose your own socket-descriptor. What if two different AA's chose
the same Regitration Token "100", then you have to give back a
TRANSMITERROR.INDICATION or some form of REGISTRATIONERROR.INDICATION to the
second guy. After all the application can live with a completely opaque
Registration / Transmission token as long as it is meaningful and unique at
the BPA, right?</pre>
</blockquote>
But this is an abstract service specification, not an API for a
particular language, so there isn't any notion of "returning" anything;
that's why this approach was taken.&nbsp; In an actual implementation you
can make this happen any way you like, so long as the application
always has some handle of some sort by which it can cancel a
transmission.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">o Section 3.5

Why even make this artificial 1023 byte limit on SSP's and scheme names?
      </pre>
    </blockquote>
    <pre wrap="">Because the offsets are 16-bit integers and we want to have room for 64 
different strings.
    </pre>
    <blockquote type="cite">
      <pre wrap="">Why constrain the endpoint ID references to 16 bit quantities when you can
make them both SDNV's?
      </pre>
    </blockquote>
    <pre wrap="">Because making them SDNVs would introduce additional parsing complexity 
without significant offsetting benefit; 1023 bytes per string is already 
long enough.  (Maybe too long.)
    </pre>
  </blockquote>
  <pre wrap=""><!---->But SDNVs could lead to smaller bundle header sizes, especially when the
Dictionary is rather small (so that most of the SDNV fields are one octet
long). But I guess the goal is to aid in quicker parsing rather than
header-size optimization here.</pre>
</blockquote>
That's right; it's a trade-off, and on this particular issue we came
down on the side of time efficiency rather than space efficiency.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">o Section 4.10.1, Page 36, towards the end of the first para.

After saying that we may be appending in new entries into the dictionary,
also add that we would be removing any unnecessary entries present in the
dictionary, perhaps?
      </pre>
    </blockquote>
    <pre wrap="">We're not requiring that an implementation do this, as it is non-trivial 
and of unclear utility.  But we're also not prohibiting it, in the event 
that some implementor gets ambitious.  Since it's in the realm of things 
that the implementation *may* do, I'd prefer to leave it out.
    </pre>
  </blockquote>
  <pre wrap=""><!---->IMHO, its probably worthwhile to put a single sentence in there to say
that Implementations MAY do this (so as to make the implementers atleast
ponder over this); Saying nothing at all about this might cause an
implementer to not even consider it. In bandwidth constrained environments,
especially when the MTU size is small, an implementer may have more
motivation for making sure that he is not shipping any stale data in his
dictionary (especially when contacts are infrequent and the BPA has all the
time to optimize its bundle-sizes), don't you think?
  </pre>
</blockquote>
Okay.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">o Section 5.1.1 Bundle Status Reports : Time of Acknowledgement

This could be okay, except that this seems like a
layering violation to me now. Why should the bundling protocol do the
business of informing the sender when the application finished processing
the data. I think that this would be left best for the application protocol
(if any) operating over the bundling protocol to do; For example, the
application protocol may choose to generate an application-level ACK (which
appears as a separate bundle) for transmission to the source.
      </pre>
    </blockquote>
    <pre wrap="">Yep, we had this discussion; the text in the spec is where it ended up.  
I think it can be argued that the bundle protocol is just providing a 
little additional service to the application here, much as the Payload 
Security Header in the security protocol is a little additional service 
to the application.  Not really mandatory, and arguably not the business 
of this protocol, but I don't see where it does a lot of harm.
    </pre>
    <blockquote type="cite">
      <pre wrap="">The key advantage is that the BPA need not keep state of an erstwhile 
session just
in case it might get an Acknowledge.Request for that session in the future.
      </pre>
    </blockquote>
    <pre wrap="">But it needn't do that anyway; the parameters to the Acknowledge.request 
provide all the information needed to issue that status report (I think).
    </pre>
  </blockquote>
  <pre wrap=""><!---->  Yeah, the Acknowledge.Request does give the BPA all it needs.
  But I was thinking that the BPA would atleast want to do some sanity
checking to make sure that the bundle creation timestamp refers to a bundle
it has seen in the past to prevent an Application Agent (which is totally
under an application control as you said) 
from generating arbitrary Acknowledge.Request
parameters. It could be a security-problem in some sense if such a sanity
check was not made. See, these are the places where the layering violation
comes to bite you.
  </pre>
</blockquote>
But if the application generated application-layer acknowledgements --
which would, like acknowledgement status reports, be distinct bundles
-- wouldn't you have the same situation?&nbsp; What makes this worse?<br>
<br>
I think this is really an architectural issue rather than a protocol
specification issue, so if you want to pursue it I would propose that
you start a new thread, which I will happily leave in the hands of
Kevin and Mike.<br>
<br>
Scott<br>
</body>
</html>

--------------060003010607020902080303--

Date: Sat, 15 Oct 2005 09:25:37 -0400
From: Manikantan Ramadas <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the current Bundling draft
Sender: [email-masked]

--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Scott,

  Here are my responses after clipping away things I am letting go,
although rather painfully on some of them :-(

> > ...

> The functions of the administrative element of the application agent are=
=20
> discussed in 4.1, 5.2, and 5.3; not a huge role, but I think it's=20
> important for anyone trying to make sense of the spec.
>=20

  Alright, now that I see these sections more closely. OK.
 =20
> >o Section 2.4.6 : Lifespan - It is specified as the length of time=20
> >following
> >the initial transmission of the bundle. But lifespan is actually the
> >time following the creation time of the bundle, as mentioned everywhere=
=20
> >else
> >in the document. Since creation time need not always be the same as the
> >initial transmission time, this needs to be fixed accordingly.
> >=20
> >
> But bundle creation time and initial transmission time are the same=20
> time.  See 2.4.11 and 4.2.
>
  In neither of these two sections do I find a reference to an "initial
transmission time". Bundle creation time is specified clearly as the time at
which the Transmit.Request was received at the BPA. But "initial
transmission time" means to me as the time at which actual transmission of
the bundle happens, which may be later in time if the bundle sat there with
a Dispatch Pending / Forward Pending retention constraint waiting for a link
to show up. Thats why I request a more accurate use of terminology in the
definition of what a Lifespan is.

> >o Section 2.4.11 Bundle Creation Timestamp :

> > ...
> Because the Bundle Creation Timestamp isn't really a time - at least,=20
> not all of it is.  The "seconds" part of the timestamp is the=20
> transmission time at seconds granularity; that time value is used to=20
> compute expiration time, and since the lifetime parameter is only at=20
> seconds granularity there's no sense in having the transmission time at=
=20
> higher resolution.  The "sequence count" part of the timestamp is just a=
=20
> counter, incremented to provide a guaranteed unique bundle ID; the=20
> nanoseconds part of a timespec isn't guaranteed to be unique, as its=20
> value will depend on how the clock is implemented.  The sequence counter=
=20
> can reset when the clock rolls over to the next second; between the two,=
=20
> you've got a unique ID that we figure is unlikely to roll over within=20
> the useful life of this protocol.
>=20

  Alright then.
 =20
> >o Section 2.5.1 TRANSMIT.REQUEST and 2.5.3 REGISTER.REQUEST:
> >
> > Do we assume the AA to choose our Registration Token and Transmission
> >Token, and not the application itself directly? I am just worried about=
=20
> >some
> >one in the middle (besides the application itself) guaranteeing that the=
se
> >tokens are unique at the BPA.
> >=20
> >
> No problem, the application agent *is* "the application itself".  The=20
> "agent" part of the name "application agent" doesn't mean that it=20
> operates on behalf of something else, it just means that it operates (as=
=20
> in a chemical "active agent").
>=20

  So, my bigger question here was, why was this approach taken instead of
letting the BPA to return a Registration Token / Transmission Token? Similar
to a socket() call that returns you a socket-descriptor instead of asking
you to choose your own socket-descriptor. What if two different AA's chose
the same Regitration Token "100", then you have to give back a
TRANSMITERROR.INDICATION or some form of REGISTRATIONERROR.INDICATION to the
second guy. After all the application can live with a completely opaque
Registration / Transmission token as long as it is meaningful and unique at
the BPA, right?=20

> > ...
> ...
> >If that earlier feedback I received months ago is still deemed to hold
> >however, I think we could at least add something on the
> >lines of : "Implementations may also have another parameter indicating t=
he
> >cause of this TRANSMITERROR.INDICATION with the indication.
> >=20
> >
> But implementations can always do whatever they like that doesn't=20
> contradict the spec.  I don't want to get into the business of=20
> enumerating everything that bundle protocol implementations are allowed=
=20
> to do.
>
  OK.
 =20
> >o Section 3.5
> >
> > Why even make this artificial 1023 byte limit on SSP's and scheme names?
> >=20
> >
> Because the offsets are 16-bit integers and we want to have room for 64=
=20
> different strings.
>=20
> > Why constrain the endpoint ID references to 16 bit quantities when you =
can
> >make them both SDNV's?
> >
> Because making them SDNVs would introduce additional parsing complexity=
=20
> without significant offsetting benefit; 1023 bytes per string is already=
=20
> long enough.  (Maybe too long.)
>

  But SDNVs could lead to smaller bundle header sizes, especially when the
Dictionary is rather small (so that most of the SDNV fields are one octet
long). But I guess the goal is to aid in quicker parsing rather than
header-size optimization here.=20

> >o Section 4.10.1, Page 36, towards the end of the first para.
> >
> > After saying that we may be appending in new entries into the dictionar=
y,
> >also add that we would be removing any unnecessary entries present in the
> >dictionary, perhaps?
> >=20
> >
> We're not requiring that an implementation do this, as it is non-trivial=
=20
> and of unclear utility.  But we're also not prohibiting it, in the event=
=20
> that some implementor gets ambitious.  Since it's in the realm of things=
=20
> that the implementation *may* do, I'd prefer to leave it out.
>=20

  IMHO, its probably worthwhile to put a single sentence in there to say
that Implementations MAY do this (so as to make the implementers atleast
ponder over this); Saying nothing at all about this might cause an
implementer to not even consider it. In bandwidth constrained environments,
especially when the MTU size is small, an implementer may have more
motivation for making sure that he is not shipping any stale data in his
dictionary (especially when contacts are infrequent and the BPA has all the
time to optimize its bundle-sizes), don't you think?

> > Last paragraph (line) of the same section, can't we make a stronger
> >requirement on keeping custodial bundles in non-volatile storage, such as
> >"custodial bundles SHOULD be kept in non-volatile storage"?
> >=20
> >
> I am resolutely avoiding the use of capitalized keywords, which I think=
=20
> make the text of a specification sound hysterical.  IETF may contradict=
=20
> me on this when we get into the RFC submission procedure, but until then=
=20
> I don't want "SHOULD" in this document.  The "if possible" clause is=20
> arguably redundant, but I think it reflects the sense of what's being=20
> said; I don't think it does any harm to leave it in.
>=20
  But those keywords are useful, and here is a place where I think it is
most appropriate, since custody transfer is one of the fundamental things
supported by the protocol. I am painfully willing to let go, if nobody else
has strong feelings over this.

> >o Section 5.1.1 Bundle Status Reports : Time of Acknowledgement
> >
> > This could be okay, except that this seems like a
> >layering violation to me now. Why should the bundling protocol do the
> >business of informing the sender when the application finished processing
> >the data. I think that this would be left best for the application proto=
col
> >(if any) operating over the bundling protocol to do; For example, the
> >application protocol may choose to generate an application-level ACK (wh=
ich
> >appears as a separate bundle) for transmission to the source.
> >
> Yep, we had this discussion; the text in the spec is where it ended up. =
=20
> I think it can be argued that the bundle protocol is just providing a=20
> little additional service to the application here, much as the Payload=20
> Security Header in the security protocol is a little additional service=
=20
> to the application.  Not really mandatory, and arguably not the business=
=20
> of this protocol, but I don't see where it does a lot of harm.
>=20
> >The key advantage is that the BPA need not keep state of an erstwhile=20
> >session just
> >in case it might get an Acknowledge.Request for that session in the futu=
re.
> >=20
> >
> But it needn't do that anyway; the parameters to the Acknowledge.request=
=20
> provide all the information needed to issue that status report (I think).
>=20
  Yeah, the Acknowledge.Request does give the BPA all it needs.
  But I was thinking that the BPA would atleast want to do some sanity
checking to make sure that the bundle creation timestamp refers to a bundle
it has seen in the past to prevent an Application Agent (which is totally
under an application control as you said)=20
from generating arbitrary Acknowledge.Request
parameters. It could be a security-problem in some sense if such a sanity
check was not made. See, these are the places where the layering violation
comes to bite you.

- Mani.

--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--sdtB3X0nJg68CQEu
Content-Type: application/pgp-signature
Content-Disposition: inline

--sdtB3X0nJg68CQEu--

Date: Fri, 14 Oct 2005 17:19:24 -0700
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the current Bundling draft
Sender: [email-masked]

Manikantan Ramadas wrote:

>Hi folks,
>
>   I just finished reading the current bundling draft, and have some
>thoughts/comments that follow. I shall go with the major ones first, and
>then follow them with the minor/rather trivial ones.
>The coolest notion in this draft is the idea of associating various
>retention constraints to the waiting bundles. I like the idea.
>  
>
Mani, thanks very much for giving this document such a close reading - 
it's really helpful, though (big surprise here) I don't necessarily 
agree with all your comments.  Some responses in-line below:

>o Page 6, description of Application agent, where the mention of the private
>control interface between the BPA and the AA's administrative element is
>made. It has been left rather abstract and unspecified on what exactly the
>AA's administrative element is doing for us and what the interface is for. 
>I would assume that the BPA would treat this as a module to generate various
>administrative records for transmission; Is there anything else the
>administrative element is supposed to do? If not, it would seem to me that
>there is no special value in abstracting away something that is actually an
>internal module of the BPA.
>
The functions of the administrative element of the application agent are 
discussed in 4.1, 5.2, and 5.3; not a huge role, but I think it's 
important for anyone trying to make sense of the spec.

>o Section 2.3.1, and 2.3.2 : It is mentioned that the requests and
>indications are consumed and issued by the "bundle protocol". I think what
>we mean here is that it is the BPA that is doing so from and to the AA. It
>would be nice if this was specified more precisely.
>  
>
Yes; done.

>And 2.3.1 is missing "i) Acknowledge.Request"
>  
>
Right, good catch.

>o Section 2.4.6 : Lifespan - It is specified as the length of time following
>the initial transmission of the bundle. But lifespan is actually the
>time following the creation time of the bundle, as mentioned everywhere else
>in the document. Since creation time need not always be the same as the
>initial transmission time, this needs to be fixed accordingly.
>  
>
But bundle creation time and initial transmission time are the same 
time.  See 2.4.11 and 4.2.

>o Section 2.4.11 Bundle Creation Timestamp :
>  Everywhere else in the spec., we have timestamps represented as POSIX
>timespec. I am wondering why the Bundle timestamp alone is in a lesser
>resolution and measured as the number of seconds since 1 Jan 2000. I first
>thought may be this was to let us be nice to those challenged bundle
>nodes such as sensor motes. But then, I see that the creation timestamp is
>only the time at which the BPA received the Transmit.Request. Since the BPA
>is expected to be capable of generating POSIX timespecs for other places in
>the protocol spec. such as in the Administrative Records, why not be uniform
>and make the Bundle Creation Timestamp be a POSIX timespec too?
>  
>
Because the Bundle Creation Timestamp isn't really a time - at least, 
not all of it is.  The "seconds" part of the timestamp is the 
transmission time at seconds granularity; that time value is used to 
compute expiration time, and since the lifetime parameter is only at 
seconds granularity there's no sense in having the transmission time at 
higher resolution.  The "sequence count" part of the timestamp is just a 
counter, incremented to provide a guaranteed unique bundle ID; the 
nanoseconds part of a timespec isn't guaranteed to be unique, as its 
value will depend on how the clock is implemented.  The sequence counter 
can reset when the clock rolls over to the next second; between the two, 
you've got a unique ID that we figure is unlikely to roll over within 
the useful life of this protocol.

>o Section 2.5.1 TRANSMIT.REQUEST and 2.5.3 REGISTER.REQUEST:
>
>  Do we assume the AA to choose our Registration Token and Transmission
>Token, and not the application itself directly? I am just worried about some
>one in the middle (besides the application itself) guaranteeing that these
>tokens are unique at the BPA.
>  
>
No problem, the application agent *is* "the application itself".  The 
"agent" part of the name "application agent" doesn't mean that it 
operates on behalf of something else, it just means that it operates (as 
in a chemical "active agent").

>o Section 2.5.11 TRANSMITERROR.INDICATION
>
>  Is there some value in having a reason-code here specifying the cause of
>the error? I think I brought it up in my comments on the previous version of
>the draft months ago, and I think the feedback was that we don't want to
>overspecify things that are more implementation dependent. I just wanted to
>bring this up once again for us to ponder over this just a little bit. There
>could be a variety of reasons why this indication gets generated, right?
>such as expiry, invalid destination end-point ID etc. It could be
>valuable to send back some information on the cause of this indication.
>
Certainly it could be, but this is strictly an implementation matter.  
It doesn't affect interoperability in any way.

>If that earlier feedback I received months ago is still deemed to hold
>however, I think we could at least add something on the
>lines of : "Implementations may also have another parameter indicating the
>cause of this TRANSMITERROR.INDICATION with the indication.
>  
>
But implementations can always do whatever they like that doesn't 
contradict the spec.  I don't want to get into the business of 
enumerating everything that bundle protocol implementations are allowed 
to do.

>o Section 3 Rearrange Paragraphs please :
>
>  I know this is a matter of style; but I have a suggestion that could
>significantly improve readability. SDNVs and Endpoint IDs seem as
>Terminology things that have to be handled before getting to the actual
>Bundle Format. I would put these sections 3.4 and 3.5 as sections 3.1 and
>3.2. Further it would improve the clarity of the discussion if we waited on
>presenting the current sections 3.2 Header Processing Flags and 3.3 Bundle
>Processing Flags until after the actual packet format of current section 3.6
>is presented. Infact since the contents of the current sections 3.2 and 3.3
>are so short, I might be tempted to not have specific sections for them, but
>place their contents inline in their space in the respective packet format
>description; but then I am not vehement on this last one, since this is purely
>style.
>
I don't think that the changes you're proposing would really improve 
readability significantly, though.  Since this is strictly a matter of 
style and personal preference, and since I'm really trying to slow down 
the level of thrashing on this document, I'm going to disagree here.

>o Section 3.5
>
>  Why even make this artificial 1023 byte limit on SSP's and scheme names?
>  
>
Because the offsets are 16-bit integers and we want to have room for 64 
different strings.

>  Why constrain the endpoint ID references to 16 bit quantities when you can
>make them both SDNV's?
>
Because making them SDNVs would introduce additional parsing complexity 
without significant offsetting benefit; 1023 bytes per string is already 
long enough.  (Maybe too long.)

>o Section 3.6.1
>
>  A quick ASCII diagram for the bit-format of the Class of Service Flags (It
>should not take more than 5 minutes to do) would be nice!
>  
>
It would take me more than 5 minutes to do, and I think these flags are 
already described clearly.

>o Section 4.6 Step 4:
>
> Towards the end of this step, may be specifically add that this bundle can
>be deleted if there are no more retention constraints (after removing the
>Dispatch constraint that is)?
>  
>
Section 4.14 already says this, though.

>o Section 4.10.1, Page 36, towards the end of the first para.
>
>  After saying that we may be appending in new entries into the dictionary,
>also add that we would be removing any unnecessary entries present in the
>dictionary, perhaps?
>  
>
We're not requiring that an implementation do this, as it is non-trivial 
and of unclear utility.  But we're also not prohibiting it, in the event 
that some implementor gets ambitious.  Since it's in the realm of things 
that the implementation *may* do, I'd prefer to leave it out.

>  Last paragraph (line) of the same section, can't we make a stronger
>requirement on keeping custodial bundles in non-volatile storage, such as
>"custodial bundles SHOULD be kept in non-volatile storage"?
>  
>
I am resolutely avoiding the use of capitalized keywords, which I think 
make the text of a specification sound hysterical.  IETF may contradict 
me on this when we get into the RFC submission procedure, but until then 
I don't want "SHOULD" in this document.  The "if possible" clause is 
arguably redundant, but I think it reflects the sense of what's being 
said; I don't think it does any harm to leave it in.

>o Section 5.1.1 Bundle Status Reports : Time of Acknowledgement
>
>  I understand that this is the time when the application itself
>acknowledges processing of the bundle, and I assume that this can be
>generated by the BPA only upon processing an Acknowledge.Request
>
>  So, I surmise that there would be no way for a BPA when it generates a
>Bundle Status Report with say all the other times as illustrated in Page 39
>to also piggyback this "Time of acknowledgment" field along, since it would
>have no idea on when (if at all) an Acknowledge.Request would be generated
>by the application.
>
Not necessarily.  An implementation could generate status reports in 
some weird way, stacking them up for radiation in a batch, and the 
acknowledgement might be requested while the Reception (or other) status 
report for that bundle is still in the batch.

> (Note that there is no mechanism for the source to
>request a Time of Acknowledgment as shown in Table 2, Page 25.) Therefore I
>would expect that a specially crafted bundle status report carrying the
>"Time of Acknowldgement" field alone would be generated upon receiving an
>Acknowledge.Request by any reasonable implementation.
>  
>
Typically, yes.  But not necessarily.

>  This could be okay, except that this seems like a
>layering violation to me now. Why should the bundling protocol do the
>business of informing the sender when the application finished processing
>the data. I think that this would be left best for the application protocol
>(if any) operating over the bundling protocol to do; For example, the
>application protocol may choose to generate an application-level ACK (which
>appears as a separate bundle) for transmission to the source.
>
Yep, we had this discussion; the text in the spec is where it ended up.  
I think it can be argued that the bundle protocol is just providing a 
little additional service to the application here, much as the Payload 
Security Header in the security protocol is a little additional service 
to the application.  Not really mandatory, and arguably not the business 
of this protocol, but I don't see where it does a lot of harm.

> The key advantage is that the BPA need not keep state of an erstwhile session just
>in case it might get an Acknowledge.Request for that session in the future.
>  
>
But it needn't do that anyway; the parameters to the Acknowledge.request 
provide all the information needed to issue that status report (I think).

>I just wanted to present this thought and hear your thoughts on this one.
>
>Now finally to the MINOR comments / trivia that caught my eye :
>
>- 3.1 Page 18, second bullet : "eight bit-flag" ==> "8-bit flag" as in the
>previous bullet.
>  
>
Nope, this is correct as written.  We're talking here about eight flags 
of one bit each, not a single 8-bit flag.

>- In the many places in the draft where we mention the phrase
>"neither exhaustive or exclusive", it should be 
>"neither exhaustive nor exclusive"
> 
>  Only in one usage of the phrase do I observe "nor".
>  
>
Good catch.  I've fixed these.

>  
>- Information Redundancy :
>
>  I notice manifestations of this at various places in the draft and it annoys
>me while reading. I hope however that it can be easily fixed.
>
> In Figure 2, Page 23, bundle header formats in the Notes area for example: We
>could do it in a more crisp fashion if we just have a single * for the
>fields Header Length, Dictionary Length and say that all of these guys are
>indeed SDNVs, and say a double ** for the Fragment Offset and Total
>application data unit fields and say that these dudes are SDNVs too and are
>present in the header only if the flags indicated so. Similar manifestations of
>Redundancy exist in the following places too. I would be a happier man if
>you fixed them too :-)
>
>  * Page 39, Notes section
>  * Page 43, Notes section
>  
>
Mani, you will unfortunately have to learn to live with this particular 
unhappiness.  It's another of those personal preference issues, and I am 
not going to be scrubbing this document yet again for this kind of thing.

>----  
>  Overall of course I am glad to see our Bundling protocol undergo all this
>evolution and slowly emerge as a more robust species :-)
>  
>
Me too.  Thanks.

Scott

Date: Fri, 14 Oct 2005 14:31:29 -0400
From: Manikantan Ramadas <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] Thoughts on the current Bundling draft
Sender: [email-masked]

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi folks,

   I just finished reading the current bundling draft, and have some
thoughts/comments that follow. I shall go with the major ones first, and
then follow them with the minor/rather trivial ones.
The coolest notion in this draft is the idea of associating various
retention constraints to the waiting bundles. I like the idea.

o Page 6, description of Application agent, where the mention of the private
control interface between the BPA and the AA's administrative element is
made. It has been left rather abstract and unspecified on what exactly the
AA's administrative element is doing for us and what the interface is for.=
=20
I would assume that the BPA would treat this as a module to generate various
administrative records for transmission; Is there anything else the
administrative element is supposed to do? If not, it would seem to me that
there is no special value in abstracting away something that is actually an
internal module of the BPA.=20

o Section 2.3.1, and 2.3.2 : It is mentioned that the requests and
indications are consumed and issued by the "bundle protocol". I think what
we mean here is that it is the BPA that is doing so from and to the AA. It
would be nice if this was specified more precisely.

And 2.3.1 is missing "i) Acknowledge.Request"

o Section 2.4.6 : Lifespan - It is specified as the length of time following
the initial transmission of the bundle. But lifespan is actually the
time following the creation time of the bundle, as mentioned everywhere else
in the document. Since creation time need not always be the same as the
initial transmission time, this needs to be fixed accordingly.

o Section 2.4.11 Bundle Creation Timestamp :
  Everywhere else in the spec., we have timestamps represented as POSIX
timespec. I am wondering why the Bundle timestamp alone is in a lesser
resolution and measured as the number of seconds since 1 Jan 2000. I first
thought may be this was to let us be nice to those challenged bundle
nodes such as sensor motes. But then, I see that the creation timestamp is
only the time at which the BPA received the Transmit.Request. Since the BPA
is expected to be capable of generating POSIX timespecs for other places in
the protocol spec. such as in the Administrative Records, why not be uniform
and make the Bundle Creation Timestamp be a POSIX timespec too?

o Section 2.5.1 TRANSMIT.REQUEST and 2.5.3 REGISTER.REQUEST:

  Do we assume the AA to choose our Registration Token and Transmission
Token, and not the application itself directly? I am just worried about some
one in the middle (besides the application itself) guaranteeing that these
tokens are unique at the BPA.

o Section 2.5.11 TRANSMITERROR.INDICATION

  Is there some value in having a reason-code here specifying the cause of
the error? I think I brought it up in my comments on the previous version of
the draft months ago, and I think the feedback was that we don't want to
overspecify things that are more implementation dependent. I just wanted to
bring this up once again for us to ponder over this just a little bit. There
could be a variety of reasons why this indication gets generated, right?
such as expiry, invalid destination end-point ID etc. It could be
valuable to send back some information on the cause of this indication.=20

If that earlier feedback I received months ago is still deemed to hold
however, I think we could at least add something on the
lines of : "Implementations may also have another parameter indicating the
cause of this TRANSMITERROR.INDICATION with the indication.

o Section 3 Rearrange Paragraphs please :

  I know this is a matter of style; but I have a suggestion that could
significantly improve readability. SDNVs and Endpoint IDs seem as
Terminology things that have to be handled before getting to the actual
Bundle Format. I would put these sections 3.4 and 3.5 as sections 3.1 and
3.2. Further it would improve the clarity of the discussion if we waited on
presenting the current sections 3.2 Header Processing Flags and 3.3 Bundle
Processing Flags until after the actual packet format of current section 3.6
is presented. Infact since the contents of the current sections 3.2 and 3.3
are so short, I might be tempted to not have specific sections for them, but
place their contents inline in their space in the respective packet format
description; but then I am not vehement on this last one, since this is pur=
ely
style.=20

o Section 3.5

  Why even make this artificial 1023 byte limit on SSP's and scheme names?
 =20
  Why constrain the endpoint ID references to 16 bit quantities when you can
make them both SDNV's?=20

o Section 3.6.1

  A quick ASCII diagram for the bit-format of the Class of Service Flags (It
should not take more than 5 minutes to do) would be nice!

o Section 4.6 Step 4:

 Towards the end of this step, may be specifically add that this bundle can
be deleted if there are no more retention constraints (after removing the
Dispatch constraint that is)?

o Section 4.10.1, Page 36, towards the end of the first para.

  After saying that we may be appending in new entries into the dictionary,
also add that we would be removing any unnecessary entries present in the
dictionary, perhaps?

  Last paragraph (line) of the same section, can't we make a stronger
requirement on keeping custodial bundles in non-volatile storage, such as
"custodial bundles SHOULD be kept in non-volatile storage"?

o Section 5.1.1 Bundle Status Reports : Time of Acknowledgement

  I understand that this is the time when the application itself
acknowledges processing of the bundle, and I assume that this can be
generated by the BPA only upon processing an Acknowledge.Request

  So, I surmise that there would be no way for a BPA when it generates a
Bundle Status Report with say all the other times as illustrated in Page 39
to also piggyback this "Time of acknowledgment" field along, since it would
have no idea on when (if at all) an Acknowledge.Request would be generated
by the application. (Note that there is no mechanism for the source to
request a Time of Acknowledgment as shown in Table 2, Page 25.) Therefore I
would expect that a specially crafted bundle status report carrying the
"Time of Acknowldgement" field alone would be generated upon receiving an
Acknowledge.Request by any reasonable implementation.

  This could be okay, except that this seems like a
layering violation to me now. Why should the bundling protocol do the
business of informing the sender when the application finished processing
the data. I think that this would be left best for the application protocol
(if any) operating over the bundling protocol to do; For example, the
application protocol may choose to generate an application-level ACK (which
appears as a separate bundle) for transmission to the source. The key
advantage is that the BPA need not keep state of an erstwhile session just
in case it might get an Acknowledge.Request for that session in the future.

I just wanted to present this thought and hear your thoughts on this one.

Now finally to the MINOR comments / trivia that caught my eye :

- 3.1 Page 18, second bullet : "eight bit-flag" =3D=3D> "8-bit flag" as in =
the
previous bullet.

- In the many places in the draft where we mention the phrase
"neither exhaustive or exclusive", it should be=20
"neither exhaustive nor exclusive"
=20
  Only in one usage of the phrase do I observe "nor".
 =20
- Information Redundancy :

  I notice manifestations of this at various places in the draft and it ann=
oys
me while reading. I hope however that it can be easily fixed.

 In Figure 2, Page 23, bundle header formats in the Notes area for example:=
 We
could do it in a more crisp fashion if we just have a single * for the
fields Header Length, Dictionary Length and say that all of these guys are
indeed SDNVs, and say a double ** for the Fragment Offset and Total
application data unit fields and say that these dudes are SDNVs too and are
present in the header only if the flags indicated so. Similar manifestation=
s of
Redundancy exist in the following places too. I would be a happier man if
you fixed them too :-)

  * Page 39, Notes section
  * Page 43, Notes section
=20
---- =20
  Overall ofcourse I am glad to see our Bundling protocol undergo all this
evolution and slowly emerge as a more robust species :-)

- Mani.
 =20
--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature
Content-Disposition: inline

--r5Pyd7+fXNt84Ff3--

Date: Mon, 10 Oct 2005 11:52:17 -0700
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] ...and with additional tweaks per this morning's discussion
Sender: [email-masked]

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

New stuff:
-    a couple of notes forbidding custody transfer and status reporting 
for administrative records;
-    an additional status report time field for time of acknowledgement;
-    an additional informative reference, to the security architecture 
overview;
-    "none:." replaced by "dtn:none".

Scott

--------------040302090008060200030200
Content-Type: application/msword;
 name="draft-irtf-dtnrg-bundle-spec-04.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-irtf-dtnrg-bundle-spec-04.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAHAAAATgMAAAAA
AAAAEAAAUAMAAAEAAAD+////AAAAAEcDAABIAwAASQMAAEoDAABLAwAATAMAAE0DAAD/////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
--------------040302090008060200030200--

Content-class: urn:content-classes:message
Date: Mon, 10 Oct 2005 12:58:32 -0400
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] DTN multicast draft
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5CDBB.D9239A7B
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C5CDBB.D9239A7B"

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

All,
=20
Attached is a potential internet-draft on which we'd like your
comments. It is titled, "Bundle Protocol Extensions to Support
Multicasting" and basically it is a writeup of the ideas that I briefed
at the July meeting at Berkeley (the powerpoint slides for which were
distributed on this list back in July). =20
=20
At the Berkeley meeting, the suggestion was made that we use actual
EIDs rather than local IDs to denote to which next-hop nodes different
copies of a multicast bundle are forwarded at a given branching point.
The suggestion was also made that we have the receiving node insert
it's EID into the custodial multicast header instead of having the
sending node insert this information, so that underlying
broadcast/multicast native network capabilities could be used for
transmission. I incorporated both of these ideas as options into the
attached draft. We may eventually want to make them standard and remove
the idea of local IDs altogether, but for now local IDs are still in
there. Local IDs are nice because they can potentially be much shorter
than EIDs, but using EIDs buy us a lot, such as:
 - the ability to target retransmissions that are initiated by custody
timer expiration, and
 - the ability to aggregate multicast custody signals on the reverse
distribution path
 - the ability to take advantage of underlying native network
broadcast/multicast
=20
There is something else that we are also not completely happy with, but
we didn't want this to delay our getting the draft out for review and
comment. This draft defines a "multicast custody signal" that would
REPLACE the "custody signal" that is defined in the bundle protocol
when reporting on the custody of bundles that have multicast custody
headers. It also redefines to what node this multicast custody signal
is sent (the previous branching point versus the custodian) in some
circumstances.  We are a bit uncomfortable changing the semantics of
the bundle protocol in this way. It would be nicer if this multicast
draft could simply be an extension and not a replacement for the
custody stuff in the bundle protocol. We need to think about that more
to see if it's possible. If so, it would be nice to get any necessary
changes into the bundle protocol before Scott declares it unchangeable.

=20
Please read the attached draft and tell us what you think. Thanks.
=20
-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D303273716-10102005>All,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D303273716-10102005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D303273716-10102005>Attached is a=20
potential&nbsp;internet-draft on which we'd like your comments. It is =
titled,=20
"Bundle Protocol Extensions to Support Multicasting" and basically it is =
a=20
writeup of the ideas that I briefed at the July meeting at Berkeley (the =

powerpoint slides for which were distributed on this list back in=20
July).&nbsp;</SPAN></FONT><FONT face=3DArial size=3D2><SPAN=20
class=3D303273716-10102005>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D303273716-10102005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D303273716-10102005>
<DIV><SPAN class=3D803324920-07102005><FONT face=3DArial size=3D2><SPAN=20
class=3D303273716-10102005>At the Berkeley meeting, the suggestion was =
made that=20
we use actual EIDs rather than local IDs to denote to which next-hop =
nodes=20
different copies of a multicast bundle are forwarded at a given =
branching point.=20
The suggestion was also made that we have the receiving node insert it's =
EID=20
into the custodial multicast header instead of having the sending node =
insert=20
this information, so that underlying broadcast/multicast native network=20
capabilities could be used for transmission. I incorporated both of =
these ideas=20
as options into the attached draft.&nbsp;We may eventually want to make =
them=20
standard and remove the idea of local&nbsp;IDs altogether, but for now =
local IDs=20
are still in there.&nbsp;Local IDs are nice because they can potentially =
be much=20
shorter than EIDs, but using EIDs buy us a lot, such=20
as:</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D803324920-07102005><FONT face=3DArial size=3D2><SPAN=20
class=3D303273716-10102005>
<DIV><SPAN class=3D803324920-07102005><FONT face=3DArial =
size=3D2>&nbsp;- the ability=20
to target retransmissions that are initiated by custody timer =
expiration,=20
and</FONT></SPAN></DIV>
<DIV><SPAN class=3D803324920-07102005><FONT face=3DArial =
size=3D2>&nbsp;- the ability=20
to aggregate multicast custody signals on the reverse distribution=20
path</FONT></SPAN></DIV>
<DIV><SPAN class=3D803324920-07102005><FONT face=3DArial =
size=3D2>&nbsp;- the ability=20
to take advantage of underlying native network=20
broadcast/multicast</FONT></SPAN></DIV></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D803324920-07102005><FONT face=3DArial size=3D2><SPAN=20
class=3D303273716-10102005></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D803324920-07102005><FONT><SPAN=20
class=3D303273716-10102005><SPAN=20
class=3D303273716-10102005>There&nbsp;is&nbsp;something else&nbsp;that =
we are also=20
not completely happy with, but we didn't want this to delay our getting =
the=20
draft out for review and comment. This draft =
</SPAN></SPAN></FONT></SPAN><SPAN=20
class=3D803324920-07102005>defines a "multicast custody signal" that =
would REPLACE=20
the "custody signal" that is defined in the bundle protocol when =
reporting on=20
the custody of bundles that have multicast custody headers.&nbsp;It also =

redefines to what node this multicast custody signal is sent (the=20
previous&nbsp;branching point versus the custodian) in some=20
circumstances.</SPAN><SPAN class=3D803324920-07102005>&nbsp;<SPAN=20
class=3D303273716-10102005> We are a bit uncomfortable changing the =
semantics of=20
the bundle protocol in this way. </SPAN>It would be nicer if&nbsp;<SPAN=20
class=3D303273716-10102005>this multicast draft could simply be =
</SPAN>an=20
extension and not a replacement for the custody stuff in the bundle =
protocol. We=20
need to think about that more to see if it's possible. If so, it would =
be nice=20
to get any necessary changes into the bundle protocol before Scott =
declares it=20
unchangeable. </SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D803324920-07102005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D803324920-07102005><SPAN =
class=3D303273716-10102005><FONT=20
face=3DArial size=3D2>Please read the attached draft and tell us what =
you think.=20
Thanks.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D803324920-07102005><SPAN =
class=3D303273716-10102005><FONT=20
face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D803324920-07102005><SPAN =
class=3D303273716-10102005><FONT=20
face=3DArial =
size=3D2>-susan</FONT></SPAN></SPAN></DIV></SPAN></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_002_01C5CDBB.D9239A7B--

------_=_NextPart_001_01C5CDBB.D9239A7B
Content-Type: text/plain;
	name="DTN-irtf-dtnrg-bundle-multicast-2005_10_07.txt"
Content-Transfer-Encoding: base64
Content-Description: DTN-irtf-dtnrg-bundle-multicast-2005_10_07.txt
Content-Disposition: attachment;
	filename="DTN-irtf-dtnrg-bundle-multicast-2005_10_07.txt"

------_=_NextPart_001_01C5CDBB.D9239A7B--

Date: Fri, 07 Oct 2005 16:55:56 -0700
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] ...with beefed-up Security Considerations
Sender: [email-masked]

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

Here's the bundle protocol spec one more time, now with an expanded 
Security Considerations section -- thanks, Howie!

The alert reader will notice that two further updates have also managed 
to find their way into this edition of the draft:

1.   For consistency, a new "time of custody acceptance" field has been 
added to the Bundle Status Report.  This saves the "time of receipt" 
field from having to do double duty, somewhat simplifying 
implementations, and it might be significant in the event that some 
future implementation introduces a non-trivial delay between bundle 
reception and acceptance of custody.

2.   A new 8-bit "flow label" field has been added to the Primary Bundle 
Header.  The intent of this field is mainly to enable 
configuration-specific QOS hints to be passed through to the convergence 
layer adapter and/or propagated to downstream routers, more or less as 
in IPv6.  I don't know exactly how it would be used yet, but this kind 
of thing keeps popping up in CCSDS protocol design discussions, so I 
think it's a potentially valuable feature that doesn't seem to cost much.

I really want not to slow down the process of getting this new draft 
started on its way to RFC-hood, so if we find either or both of these 
updates to be controversial I will gladly drop it/them like steaming 
tarantulas.  If not, I would suggest that we start RFC-ing this draft 
soon, like maybe October 17.

Scott

--------------020106080200060501040605
Content-Type: application/msword;
 name="draft-irtf-dtnrg-bundle-spec-04.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-irtf-dtnrg-bundle-spec-04.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAHAAAAOwMAAAAA
AAAAEAAAPQMAAAEAAAD+////AAAAADQDAAA1AwAANgMAADcDAAA4AwAAOQMAADoDAAD/////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
--------------020106080200060501040605--

Date: Wed, 05 Oct 2005 07:07:13 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] bundle protocol spec 4.0
Sender: [email-masked]

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

Attached is a small update to the bundle protocol spec, reflecting the
outcome of our discussions over the past three months.  We will also be
inserting a significantly beefed-up "Security Considerations" section as
soon as Howie finishes drafting it.  At that point I think the protocol
will be stable enough for us to start taking the document forward to RFC
status, unless somebody sees some major problem in this draft -- in
which case, please speak up very soon.

Scott

--------------050406090104000402050909
Content-Type: application/msword;
 name="draft-irtf-dtnrg-bundle-spec-04.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-irtf-dtnrg-bundle-spec-04.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAHAAAAMwMAAAAA
AAAAEAAANQMAAAEAAAD+////AAAAACwDAAAtAwAALgMAAC8DAAAwAwAAMQMAADIDAAD/////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
--------------050406090104000402050909--

Content-class: urn:content-classes:message
Date: Tue, 4 Oct 2005 20:08:51 -0700
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] test message
Sender: [email-masked]

Please ignore.