Re: Updated version of FLUTE-revised

Hi,

Based on the emails the last weeks, I think there is need for one more
update before IETF last call.

When it comes to the IETF-types review I have put in a note that I will
do that during IETF last call.

[email protected] skrev 2009-12-29 10:20:
> 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.

It seems that this should be updated in the text before IETF last call.

>       
>    > 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).      

It is in the grey zone, but I don't think there will be any issues with
using an informational reference in this case.


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

To my recollection this is where ALC ended up.

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

The changes may look bigger than they are. First of all there has been a
change in order of the statements. Secondly, it does contain the
appropriate disclaimer due to old copyright. So to me it appears to be
correct.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------