Subject: Re: [Rmt] Updated version of FLUTE-revised

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Jan 2010 11:53:36 +0100

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-masked] 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-masked]
----------------------------------------------------------------------

---

From: Vincent Roca <[email-masked]>
Date: Tue, 19 Jan 2010 10:08:01 +0100

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.

---

> [...]
> [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.

> [...]
> [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.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jan 2010 17:05:05 +0100

Thanks Vincent,

I have checked the new version and I see one issue that I would prefer
to be fixed before going out on IETF last call.

The ESP and WEBRC references are listed as informational. But due to the
text requiring their implementation I see them as being normative now.
Especially WEBRC that really should be listed as a downref in the IETF
last call.

Can you fix this the next few days?

Cheers

Magnus Westerlund

---

From: <[email-masked]>
Date: Thu, 21 Jan 2010 15:02:52 +0100

Thanks Vincent. Here's a tiny fix to consider in this para:

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

Change "...that the out-of-band transmission ..." to "...that any out-of-band transmission ..." to avoid implying that out-of-band is mandatory or recommended or all cases.

Cheers, Rod.

ext Vincent Roca wrote:

Mike, Toni,

Cheers,

   Vincent

---

---

[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.
_______________________________________________
Rmt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rmt

---

From: <[email-masked]>
Date: Thu, 21 Jan 2010 15:16:47 +0100

Magnus is spot on.

ESP. Section 7.5 makes this clear so [30] does indeed need to be normative

WEBRC. Section 1.1.4 states "implementations of ALC MUST support the WEBRC [27]  multiple rate congestion control scheme [2]." and thus implicitly indicate that ""implementations of FLUTE MUST support the WEBRC" since "All of the environmental requirements and considerations that apply to the ALC building block [2] and to any additional building blocks that FLUTE uses also apply to FLUTE." And so, [27] should also be normative. (Note, this does not make implementation of WEBRC manditory, but it makes the ability to support an implementation of WEBRC manditory - which seems perfect as that ensures the public Internet transport layer congestion defence is supported without overloading the various wireless broadcast systems that deal with congestion/prioritisation in other ways).

(I assume WEBRC is normative in ALC!)

Cheers, Rod.

ext Magnus Westerlund wrote:

Thanks Vincent,

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden| mailto: [email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Jan 2010 15:32:13 +0100

[email-masked] skrev 2010-01-21 15:16:
> WEBRC. Section 1.1.4 states "implementations of ALC MUST support the
> WEBRC [27]  multiple rate congestion control scheme [2]." and thus
> implicitly indicate that ""implementations of FLUTE MUST support the
> WEBRC" since "All of the environmental requirements and considerations
> that apply to the ALC building block [2] and to any additional building
> blocks that FLUTE uses also apply to FLUTE." And so, [27] should also be
> normative. (Note, this does not make implementation of WEBRC manditory,
> but it makes the ability to support an implementation of WEBRC manditory
> - which seems perfect as that ensures the public Internet transport
> layer congestion defence is supported without overloading the various
> wireless broadcast systems that deal with congestion/prioritisation in
> other ways).
> 

Yes, and there where no issues with the downref at that time. So flute
shouldn't either have any.

Cheers

Magnus Westerlund

---

From: Vincent Roca <[email-masked]>
Date: Fri, 29 Jan 2010 11:56:57 +0100

Hello,

Good points. ESP/WEBRC references are now normative and I also
corrected "...that any out-of-band transmission ..." as Rod suggested.

Cheers,

    Vincent