Re: Updated version of FLUTE-revised

Mike, Toni,

Here is an answer to your emails.
Thanks for your feedback.
Magnus, I think that the I-D is now ready.

Cheers,

   Vincent

---

> Vincent, RMT,
> I suggest replacing the second to last paragraph of Section 3.3 to the attached.
> (There were some grammar errors, and some ambiguities, that I think the replacement
> text cleans up.)

[VR] I've copied and paste your text in the I-D (from your second email with the
slightly updated version).

> Also, my affiliation at the end was changed to Qualcomm, but the affiliation on the
> top right header of the first page still reads Digital Fountain and this should
> also be changed.

[VR] Corrected. Sorry for the mistake.


---

> [...]
>
> > Clarified how to reliably deliver the FDT in Section 3.3.
>
> [Toni] I think Mike's new wording in his posting on Tue 29-Dec-2009 is a bit clearer
> as it goes "one file, one FDT instance", "+longer FDT instance", "many files, one FDT
> instance (including the longer FDT instance)", "many files, many FDT instances (including
> longer FDT instances)". However, the section 3.3 still misses one point. Namely,
> information content delivered by an FDT instance can be acquired out-of-band, also. This
> does not remove the need to emphasize relative higher reliability protection for FDT
> delivery but means that there are other ways than the ones stated, including out-of-band
> methods. As out-of-band methods are out of scope of the spec, it would be sufficient to
> mention these in one sentence.

[VR] You're right. I've added a small paragraph for the case of out-of-band transmission
of FDT information.

   Sometimes the various attributes associated with files that are to be
   delivered within the file delivery session are sent out-of-band
   (rather than in-band, within one or several FDT Instances).  The
   details of how this is done are out of the scope of this document.
   However, it is still RECOMMENDED that the out-of-band transmission be
   managed in such a way that a receiver will be able to recover the
   attributes associated with a file with as much or greater reliability
   as the receiver is able to receive enough packets containing encoding
   symbols to recover the file.

> [...]
>
>    > Updated the security section to define IPsec/ESP as a mandatory to implement security solution in Section 7.5.
>
> [Toni] The body text in -08 spec is written so that it gives one impression that IPsec/ESP
> is mandatory to implement and optional to use _because_ ALC requires this, too. If that is
> indeed the case (ALC does REQUIRE it), I'm fine with this additional constraint. Can you
> verify?

[VR] Yes, our documents is aligned on ALC recommendations in terms of security. I confirm.

> Lastly, I have one new one. Since RFC3920 times the IETF boiler plate, legal & license
> texts have changed quite a bit. I thought I used the most recent one in -07 version dated
> August 6, 2009. Now I see big changes again in -08 vs. -07. Can you highlight what was
> changed and verify that the legal statements are up to date?

[VR] You're right, many aspects have changed in the boiler plate. Since I'm using
the latest xml2rfc version (v1.35pre1) and did not change our xml document header,
I'm rather confident WRT the correctness of the output. Anyway, the RFC Editor will
fix it if needed.