Subject: Re: [dtn] draft-ietf-dtn-bpbis-01.txt

From: Brendan A R Sechter <[email-masked]>
Date: Sun, 28 Feb 2016 22:04:42 -0600

Hello-

I have some thoughts on some of the open issues at the end of the bundle
protocol draft.

> 13.3. Implementation Architectures
>
> Should the BP spec be divided into two documents? One to talk about
> conops and context and one that focuses specifically on the
> protocol?

If not two documents, a clear division in one document makes sense.

> 13.5. 13.2. Primary block CRC type
>
> What are the best CRC options to support here?  CRC-16-ARINC, CRC-
> 16-CCITT, CRC-16-CDMA2000, CRC-16-DECT, etc.?

What is being used in the field?  All of the above are 16 bit.  Does it
make sense to use more or less bits (CRC-1/CRC-64)?  Would using a hash or
checksum function ever make sense?

> 13.7. Clearing flag
>
> Should a node that is able to process a given extension block be
> permitted to clear block's "Block was forwarded without being
> processed" flag?

Does it make sense to have two flags?
Last hop, block forwarded without being processed.  Must be cleared if
processed.
Any hop, block forwarded without being processed.  Can not be cleared once
set.

The alternative is to treat it as a dirty flag that can be cleared
depending on the block type (or subtype).  In this case, what is permitted
needs to specified for each block type.  In some cases the may be "never
clear".  In others, it may be implementation dependent.

Just to throw a passing thought on the table- a block modified flag.  Or
two (last hop/any hop).

> 13.9. Block multiplicity
>
> Would it be good to restrict BP extensions to one extension block
> per extension per bundle?

In theory one block per extension per bundle could be limiting.  I am not
convinced it will be an issue in practice.  Are there any concrete use
cases that require multiple extension blocks of the same type?  The only
theoretical example I can think of is adding multiple variations of the
same extension to a bundle.  For example, maybe encrypting it multiple
times with different algorithms.

Regards,
-Brendan

---

From: Carlo Caini <[email-masked]>
Date: Mon, 29 Feb 2016 11:58:41 +0100

Dear Brendan,
   I have read your interesting comments. Concerning the last, block 
multiplicity, I think that apart from security, another case of 
multiple blocks of the same type is that of the metadata block 
extension, as defined in RFC6258. By reading the RFC it seems that 
you have one block for each metadata type, and of course it may 
happen to have more than one metadata type attached to the same 
bundle, i.e. multiple blocks.
Actually the text does not consider that metadata is a plural name, 
which can lead to a bit of ambiguity. I would interpret "the metadata 
itself" as one datum, or as multiple data of the same kind.
Yours,
Carlo

>        - Metadata Type field (SDNV) - indicates which metadata type is
>          to be used to interpret both the metadata in the metadata field
>          and the EID-references in the optional Block EID-reference
>          count and EID-references field (if present).  One metadata type
>          is defined in this document.  Other metadata types may be
>          defined in separate documents.
>
>          - Metadata field - contains the metadata itself, formatted
>          according to the metadata type that has been specified for this
>          block.  One metadata type is defined in 
> <https://tools.ietf.org/html/rfc6258#section-4.1>Section 4.1.  Other
>          metadata types may be defined elsewhere, as discussed in
>          <https://tools.ietf.org/html/rfc6258#section-4>Section 4.

At 05:04 29/02/2016, Brendan A R Sechter wrote:
>Hello-
>
>I have some thoughts on some of the open issues at the end of the 
>bundle protocol draft.
>
>What is being used in the field?  All of the above are 16 bit.  Does 
>it make sense to use more or less bits (CRC-1/CRC-64)?  Would using 
>a hash or checksum function ever make sense?
>
> > 13.7. Clearing flag
> >
>Last hop, block forwarded without being processed.  Must be cleared 
>if processed.
>Any hop, block forwarded without being processed.  Can not be 
>cleared once set.
>
>depending on the block type (or subtype).  In this case, what is 
>permitted needs to specified for each block type.  In some cases the 
>may be "never clear".  In others, it may be implementation dependent.
>
>Just to throw a passing thought on the table- a block modified 
>flag.  Or two (last hop/any hop).
>
> > 13.9. Block multiplicity
> >
>In theory one block per extension per bundle could be limiting.  I 
>am not convinced it will be an issue in practice.  Are there any 
>concrete use cases that require multiple extension blocks of the 
>same type?  The only theoretical example I can think of is adding 
>multiple variations of the same extension to a bundle.  For example, 
>maybe encrypting it multiple times with different algorithms.
>
>Regards,
>-Brendan
>_______________________________________________
>dtn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dtn

---

From: Brendan A R Sechter <[email-masked]>
Date: Mon, 29 Feb 2016 14:35:43 -0600

Carlo-

I think that RFC6258 may be in a chicken-egg scenario.  If multiple blocks
of the same type are allowed, all the thought and complexity that needs to
go into multi-item blocks can be sidestepped.  Had RFC5050 specified one
block per type, that probably would have been incorporated into the thought
process that created RFC6258.  Either solution is workable.

I think there is a choice between two strategies with relatively
straightforward ramifications.  The first choice is permitting multiple
extension blocks of the same type in each bundle.

The second choice is one extension block per extension per bundle.  This
only requires a block type, not a block number.  A solution for multiple
items in a block is also required.  The simplest solution is to only allow
one item per bundle.

A couple of different extensions is another option.  To use metadata as an
example, metadata and multi-metadata.  Alternatively, some blocks could
simply be defined as multi-item with no need for a separate single item
type.  Blocks could have a subtype (single item, multi item), an item count
or a next item offset (like IPv6 extension headers).

Insertion or deletion of metadata in a multi-metadata block would consist
of adding or deleting members from the block.  This probably implies
removing or adding the block when the item count changes to or from zero.
Doing something like encrypting an entire block is a lot easier than only
targeting some of the items in a multi-item block.

I suspect a certain amount of complexity would be involved in merging an
item into a multi-item block.  This complexity might reduce redundancy
(boilerplate block fields).  The notion of merging items into a multi-item
block may be moot for many block types.  To what extent do blocks need to
be modified as they move from node to node?  To what extent is modifying
blocks permissible from a security standpoint?

I suspect that most of the time multiple blocks of the same type in a
single bundle will be unnecessary.  Metadata may be a concrete counter
example.

Regards,
-Brendan

On Mon, Feb 29, 2016 at 4:58 AM, Carlo Caini <[email-masked]> wrote:

> multiplicity, I think that apart from security, another case of multiple
> blocks of the same type is that of the metadata block extension, as defined
> in RFC6258. By reading the RFC it seems that you have one block for each
> metadata type, and of course it may happen to have more than one metadata
> type attached to the same bundle, i.e. multiple blocks.
> Actually the text does not consider that metadata is a plural name, which
> can lead to a bit of ambiguity. I would interpret "the metadata itself" as
> one datum, or as multiple data of the same kind.
> Yours,
> Carlo
>
>
>>          block.  One metadata type is defined in <
>> https://tools.ietf.org/html/rfc6258#section-4.1>Section 4.1.  Other
>> Any hop, block forwarded without being processed.  Can not be cleared
>> once set.
>>