Re: Updated version of FLUTE-revised

Hi Vincent,

Excellent work.
The email you sent started to get quite long so I re-instantiated the issue list using your change log found in -08.

   > Added clarification for the use of FLUTE for unicast communications in Section 1.1.4.  

[Toni] This was a good addition as it adds clarity for applicability of FLUTE.

   > 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.
      
   > Clarified how to address FDT Instance expiry time wraparound with the notion of "epoch" of NTPv4 in Section 3.3.  

[Toni] I think this was good, and reading the referenced NTPv4 I agree that it can be an informative reference. I think that was also Magnus comment earlier -- i.e. add an informative reference. After all it is about sophisticated deduction of target epoch, not about implementation of NTPv4 (that's why I do not see it as normative).      

   > Clarified what should be considered as erroneous situations in Section 3.4.1 (definition of FDT Instance ID).  
   > In particular a receiver MUST be ready to handle FDT Instance ID wraparounds and missing FDT Instances.  

[Toni] Yes, this is now in according to what we discussed earlier in the longer comments-email.

   > 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?

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?
 
Regards,
 Toni