[dtn-interest] some comments on draft-zinky-dtnrg-erasure-coding-extension

["Fall, Kevin" <[e-mail]>]

I was reading this over yesterday.  Here are some notes I made...

        this document really defines a new, different architecture that seems
        to use DTN as a sort of transport mechanism underneath

        yet it also seems to liberally make changes in a variety of bits and
        pieces of the existing structure, protocols and even architecture

        I initially expected the EC framework to be at a CL.  The document
        needs a layering diagram in any case.

        I have concerns about the idea of typed data transfer (requiring IANA)
        in addition to Handling Instructions (due to complexity)

        specific to EC:

        What about ALC (RFC5775) and LCT (RFC5651)?  or FLUTE (RFC6726)?
        ALC combines
                Layered Coding Transport (LCT) building block [RFC5651]
                FEC building block [RFC5052]
                multiple rate congestion control building block [RFC2357]

       while those are sort of IP-specific, can't their frameworks be re-used here?

        why change the name of source symbol to Chunk?
        why change FEC Payload ID to "Encoding Vector"
        saying the encoding data is the "same length as the chuks": same as
                they ARE the chunks?
        Encoding set: why does it have to be a set of LINEAR equations?  What if you have some other type of code?
        "some informtaion is put in the bundle primary block, such as the Data Object
        Transfer Specification"

        "Handling specification" - does this conflict with priority?

        I find 3.1 sort of backward.  It says you have:

        data object -> encodings -> bundles

        I'd have expected this framework as a CL as thus:

        data object -> bundles -> encoded bundles

        Requirements in 3.1: divide into equal sized blocks, and assign UUID
        (ordering is required! -> what does this really imply)

        "The transfer spec cross cuts multiple layers by adding parameters to the
        bundle header, extension blocks and Data Object's internal metadata".. uh ho.

        There is a new (big) concept of typed data (data objects and transfer
        specifications)


        Feedback messages - are these more general?

        "Early research suggests" (sect 6.4) - reference?