headers
brian.adamson | 2 Nov 2011 16:13
Picon
Picon
Favicon

WG Last Call: draft-ietf-rmt-flute-sdp-01


The  FLUTE SDP " draft-ietf-rmt-flute-sdp-01" is ready for RMT Working Group Last Call.

Please provide any final comments on this document by 18 November 2011.  Unless there are objections, this
will be submitted for publication at that time.

This last call request is also being cross-posted to the MMUSIC list that may also wish to review this
document.  For their background, the FLUTE SDP document was originally written many years ago and was
tabled during the long period it took to finalize some details of the revised FLUTE protocol
specification upon which the FLUTE SDP document depends.  We now have a sufficiently finalized version of
FLUTE (soon to be submitted for publication) that we are ready to move this document along.  The document
was updated to be consistent with the work that has been accomplished since its original inception.

best regards,

Brian Adamson
brian.adamson <at> nrl.navy.mil
Permalink | Reply | 2 comments |
headers
Vincent Roca | 4 Nov 2011 14:56
Picon

About UOD RaptorQ FEC Scheme

Mike/Thomas,

During IETF 80, in March, you introduced the UOD RaptorQ scheme and asked
the opinion of the WG. As you certainly noticed, with colleagues we have carefully
scrutinized your proposal and presented our conclusions during IETF 81 in:
	http://www.ietf.org/proceedings/81/slides/rmt-2.pdf
plus an associated paper with more scientific background:
	http://hal.inria.fr/inria-00612583/en

Our conclusions on UOD (and PET, "Priority Encoding Transmission", that is closely
related) are far from neutral. It was 3 months ago. You didn't answer and I see that
you did not update the UOD RaptorQ scheme either. How should we interpret it?

I'm sure you also noticed our approach, GOE, that addresses the same UEP and
"file bundle protection" goals. If ever you have comments, we'd be glad to discuss.

Regards,

  Vincent
Permalink | Reply | 0 comments |
headers
Vincent Roca | 15 Nov 2011 10:56
Picon
Picon
Favicon

Re: WG Last Call: draft-ietf-rmt-flute-sdp-01

Hello everybody,

Here are a few comments for this I-D (I haven't finished though, more to come
next week).
Cheers,

   Vincent
---

** Section 3. "FLUTE Descriptors":
This section mentions, as an optional parameter, the FEC OTI.
I've been confused by the use of "FEC Object Transmission
Information" which refers to what is described in RFC5052,
namely the association of {Mandatory, Common and
Scheme-Specific} information. And this is per object, whereas
we are not, at SDP level, discussing objects but FLUTE sessions.

Even if the note on out-of-band FEC OTI (just after the list) and
Section 3.7 clarify what is meant here, I suggest to use a different
wording than FEC OTI in this I-D. It's really misleading.

** Section 3.5. "Session Timing Parameters"
Are there good reasons to require that SDP descriptions include
a start and end time? I agree it's good practice for the "start time".
But I'm not sure the end time is always known at session start.

Second paragraph, same section:
   "Note, implementers may assume reasonable clock synchronisation
   between ..."
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vincent Roca | 25 Nov 2011 18:41
Picon
Picon
Favicon

Re: WG Last Call: draft-ietf-rmt-flute-sdp-01

Hi,

As promised, here are my comments. You can ignore my previous
email, this one encompasses the comments I've made last week.

Cheers,

   Vincent

--
** Section 3. "FLUTE Descriptors":
This section mentions, as an optional parameter, the FEC OTI.
I've been confused by the use of FEC Object Transmission
Information which non ambiguously refers to what is described
in RFC5052, namely the association of {Mandatory, Common and
Scheme-Specific} information. And this FEC OTI is per object,
whereas we are not, at SDP level, discussing objects but sessions.

The note on out-of-band FEC OTI (just after the list) clarifies
the point, as well as Section 3.7 "FEC Object Transmission
Information". If I understand correctly, the goal is just
to communicate which FEC scheme(s) may be used by the sender
(and should be supported by a receiver).

I suggest to use a different wording than FEC OTI throughout
this I-D, since this is misleading.

** Section 3.2.1.  Composite Session Semantics for FLUTE Sessions
I find this section a bit confusing on what is mandatory or useful.
Okay for the first paragraph, but the second paragraph says:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane