Scott replied:
----Original Message-----
From: dtn-interest-admin@m=
ailman.dtnrg.org=20
[mailto:dtn-interest-=
admin@mailman.dtnrg.org] On Behalf Of=20
Scott Burleigh
Sent: Saturday, June 24, 2006 9:37 AM
To: DTNRG
Subject: Re: [dtn-interest] Comments re: tweaked bundle protocol spec

Symington, Susan F. wrote:

I think the following =
paragraph is not true and so should be
removed:

"Note that removal of strings from the dictionary at a given point in a =
bundle's end-to-end path, and attendant adjustment of endpoint ID
references in the blocks of that bundle, may make it necessary to
re-compute values in one or more of the bundle's security blocks."

The security authenticators are calculated over the actual values in
the dictionary and not the references to the dictionary, so as =
long as the endpoint ID references are adjusted correctly when the =
dictionary
is modified, there should be not problem.

Even if the strings are =
removed from the dictionary?  Wouldn't that=20
invalidate the security blocks?
If the value of a given string in the dictionary is =
included in the
canonical form of the bundle over which a security authenticator is
calculated, then that string must be in the dictionary both when the
security authenticator is calculated at the PSH-source (for example)
and when the security authenticator is verified at the PSH-destination.
The string does not necessarily have to be located at the same offset
in the dictionary, but it must be in there.  If such a string were to
be removed from the dictionary, then the authenticator will not
validate.
This really has nothing to do with the =
paragraph above that I
am objecting to though. The paragraph above says that when the string
is removed, causing the offsets of other strings to change, the
authenticator would need to be recalculated. Recalculating the
authenticator wouldn't help. Such a string nust not be removed, nor
would it be.

A node must not remove a string from the =
dictionary if that string is
in the canonical form of the bundle that was used to calculate one of
the security authenticators in the bundle.

Suppose that an authenticator is =
calculated at security source node A,
the bundle is forwarded to next node B and at node B a string is
removed from the dictionary, causing all of the offsets in the
dictionary to change, and finally the bundle is forwarded to security
destination C. I don't see how there would ever be a need for node B to
recalculate the authenticator. If node B were to recalculate this
authenticator, then node A would no longer be the security source. No
node on the way from the security source to the security destination
should be changing the value of the security authenticator.

Scott replied:
----Original Message-----
From: dtn-interest-admin@mailman.dtnrg.org 
[mailto:dtn-interest-admin@mailman.dtnrg.org] On Behalf Of 
Scott Burleigh
Sent: Saturday, June 24, 2006 9:37 AM
To: DTNRG
Subject: Re: [dtn-interest] Comments re: tweaked bundle protocol spec

Symington, Susan F. wrote:

I think the following paragraph is not true and so should be
removed:

"Note that removal of strings from the dictionary at a given point in a bundle's end-to-end path, and attendant adjustment of endpoint ID
references in the blocks of that bundle, may make it necessary to
re-compute values in one or more of the bundle's security blocks."

The security authenticators are calculated over the actual values in
the dictionary and not the references to the dictionary, so as long as the endpoint ID references are adjusted correctly when the dictionary
is modified, there should be not problem.

Even if the strings are removed from the dictionary?  Wouldn't that 
invalidate the security blocks?
If the value of a given string in the dictionary is included in the
canonical form of the bundle over which a security authenticator is
calculated, then that string must be in the dictionary both when the
security authenticator is calculated at the PSH-source (for example)
and when the security authenticator is verified at the PSH-destination.
The string does not necessarily have to be located at the same offset
in the dictionary, but it must be in there.  If such a string were to
be removed from the dictionary, then the authenticator will not
validate.
This really has nothing to do with the paragraph above that I
am objecting to though. The paragraph above says that when the string
is removed, causing the offsets of other strings to change, the
authenticator would need to be recalculated. Recalculating the
authenticator wouldn't help. Such a string nust not be removed, nor
would it be.

A node must not remove a string from the dictionary if that string is
in the canonical form of the bundle that was used to calculate one of
the security authenticators in the bundle.

Suppose that an authenticator is calculated at security source node A,
the bundle is forwarded to next node B and at node B a string is
removed from the dictionary, causing all of the offsets in the
dictionary to change, and finally the bundle is forwarded to security
destination C. I don't see how there would ever be a need for node B to
recalculate the authenticator. If node B were to recalculate this
authenticator, then node A would no longer be the security source. No
node on the way from the security source to the security destination
should be changing the value of the security authenticator.

On Wed, Jun 14, 2006 at 09:33:35AM -0700, Scott Burleigh wrote:

I think we may just be grappling with a difference of opinion over what 
the purpose of this document is.

My concept is that it's supposed to define the bundle protocol in 
sufficient detail to enable the development of multiple interoperable 
implementations -- where "interoperable" means that each implementation 
does everything that the spec says it is required to do under all the 
circumstances enumerated in the spec -- and not much else.  It's 
normative and ideally it's very terse, so that one can fairly easy be 
sure that every bit of required behavior is implemented.

In practice we also include a good deal of text that is informative 
rather than normative, without which the normative stuff wouldn't make 
any sense.  There are even a few helpful hints to the implementer, but 
in general it's not intended to be a program spec.  A Bundle Protocol 
Implementer's Companion would be a darned good idea, and I would 
certainly applaud the inclusion of loads of implementation hints in that 
(separate) document.  I think they should be kept to an absolute minimum 
in the Bundle Protocol spec, though, and I don't think the ones you're 
talking about here are so critically important that an interoperating 
implementation can't be developed without them.

I agree with this.  It would be sort of like splitting information
between CCSDS Blue and Green books.  If an implementer's guide existed,
that would be the place where I'd expect to see this topic treated.  I
guess since it doesn't exist though (yet?), I assumed that the
bundle-spec was the place where it had to go.  If there's a plan to start
an implementer's guide, that would obviously be superior.

One thing that I drew up, which would be really handy to have in an
implementer's guide is a flow diagram that shows all the movements
between the forwarding/dispatching/etc activities listed in Section 4 of
the bundle-spec.  This picture shows a basis for how the code should be
plumbed together adds a lot of clarity to what the overall step-by-step
process for operating on bundles is.  I can ASCII-ify this if the group
starts an implementer's guide.

On Tue, Jun 13, 2006 at 09:18:14PM -0700, Scott Burleigh wrote:

It adds zero complexity to simply note that if an implementation decides
to use those bits for something, then it should check that whoever set
them is authorized to do that.

Okay, zero complexity, but isn't it also zero value added?

I agree, zero-value is added to the protocol.  Positive value is added
though if implementers can the spec and being able to see what the byte
is intended for and have a hint at how they might properly use it, which
the 05 document does not make possible :).  That's all I'm trying to
suggest.

FWIW, these comments were based on implementation experience working
from the draft and refering to the DTN2 RI in several places where the
draft is nebulous.  One other thing I noted was that some suggested
proceedures for registration management would be valuable, but these are
fairly orthogonal to the bundle-spec, and could be done as a separate
short document; I don't see any need to muck up the bundle-spec with
them.

On Tue, Jun 13, 2006 at 01:20:04PM -0700, Scott Burleigh wrote:

If this is the position to be taken, then the convergence layers that use
the priority bits need to somehow check that a sending EID is authorized to
use the level that's being passed in by the bundle protocol, and this 
should
be noted in the section on services that convergence layer protocols need
to perform.

I don't understand why there's any particular need for this additional 
complexity.  What fails if we just leave the spec exactly the way it is, 
and why is the bundle protocol responsible for preventing whatever sort 
of failure that is?

It adds zero complexity to simply note that if an implementation decides
to use those bits for something, then it should check that whoever set
them is authorized to do that.
I agree fully that there's no point in a
bundle agent itself checking, if it doesn't do anything with those bits,
but if a convergence layer uses them, and they're passed in un-checked, then
that convergence layer should probably be checking them.

If there's use, but no checking of authorization, then we all just set
'expedited' on everything we send and laugh at rare souls who don't.

On Tue, Jun 13, 2006 at 11:45:17AM -0700, Scott Burleigh wrote:

2) The two bits of the COS field that are defined don't have their
   semantics defined or even suggested.  Presumably a convergence
   layer should use these to sequence its queues in some way, but
   the draft does not seem to suggest this or mention it in any way.
   This should probably be resolved, although it is not as urgent as
   the first point.  Also, it is not mentioned whether these bits
   should be used in sequencing application data units that are queued
   for delivery to passive registrations.  This should also be resolved
   with a sentence or two.

The definition of the Class of Service Flags in 3.6.1 explains that 
these two bits indicate the bundle's priority, a value from 0 (lowest) 
to 2 (highest), with 3 reserved.  The bundle protocol itself is not 
sensitive to priority; convergence layer adapters may use this value 
however they see fit.

Maybe that last sentence should work its way into the draft.  That would
clear up the situation.

It seems to be a little silly though for the convergence layers to
potentially treat some bundles differently, when they wind up in a queue
for a passive registration at the bundle agent anyways, where the
application data from expedited bundles is not going to take any
precedence over that from previously received and queued bulk bundles.
Why rush across the convergence layer, only to get stuck at this other
potential bottleneck?

A more architectural question is why only have 2 bits of the COS field
defined and 6 reserved, when we could just use all 8 and have 256
codepoints?

They're not codepoints, they're priority levels.  Certainly we could 
have more than three of those, but it hasn't yet become obvious that 
there's any need for more than three levels of priority in this traffic; 
indeed, lots of network protocols seem to get along without any at all.

I agree.  But, why is there a need for 3 levels then?  Why not 2?  Why
not none?  Three seems to offer 'some' differentiation, but not enough
to actually be useful to most of the people who would use
prioritization.

We briefly discussed using the remaining six bits for a "flow label" 
value (which some convergence layer adapters might map to something like 
a code point), but we reached no agreement that this would be useful.  
Maybe some requirement will emerge in the future.

To my knowledge, the DTN2 RI doesn't use the priority bits in the
convergence layers it implements, although I could be wrong.  Maybe
someone more familiar with that code could say for sure.  Does ION?
My question is, if we don't want to define the 6 reserved bits, then is
there any reason we have to define the 2 priority bits now?  Can we just
leave the whole byte reserved for some future QoS use?  It's not clear
to me that there's any requirement to define these 2 bits right now.

Once the base bundle spec is done, it might make more sense to come back
and do QoS as an extension header, but leave it out for now.

Most instances I know of where classes of service are actually
used, require more than the 3 generic levels that the bundle-spec-05 allow.
For instance, the ATN stack uses 15 levels of CLNP priority, and ICAO's
Aeronautical Mobile Service uses 6 levels of message priority.  Of course,
no matter how you use the COS field, it only makes sense to use it at all
if its meaning is agreed on throughout the entire DTN in question, and 
there
is some form of authorization used to make sure that the bits are only set
by applications as policy allows.

That might be true if the Bundle Protocol actually used the priority 
level in some way, but it doesn't; it merely passes it through to the 
convergence layer protocol, for whatever purpose seems appropriate at 
that layer.  Over time we may determine that the Bundle Protocol itself 
actually cares about Class of Service in some way.  We haven't yet 
reached anything resembling consensus on this, though.

If this is the position to be taken, then the convergence layers that use
the priority bits need to somehow check that a sending EID is authorized to
use the level that's being passed in by the bundle protocol, and this should
be noted in the section on services that convergence layer protocols need
to perform.