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 co=
me
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 ..."

Is it a "may" or a "SHOULD"? Having on one hand a "required
timing parameter" and on the other hand a weak recommendation
on time synchronization seems strange to me.


** Section 3.7. "FEC Object Transmission Information"
There is a paragraph on Congestion Control aspects that says:

   The identification and description of any congestion control (CC)
   instance related to layered media (multiple FLUTE channels) is
   orthogonal to the FEC declarations and other aspects of this
   document.  Hence, CC descriptions are not in scope of this document.

Two comments:
- CC discussion should not be placed in a section dedicated
  to FEC OTI. It's worth a separate section.
- why is CC considered as totally out of scope whereas its use is
  considered as an option in flute-revised (see section 4. "Channels,
  congestion control and timing" of this I-D) and whereas it is
  RECOMMENDED to use in LCT (section 4.3 of RFC5651).


** Section 5. "Security Considerations":
This section should emphasize the importance of providing
integrity and authentication guaranties to SDP instances.
This is already addressed in flute-revised, so it's not a big deal.
A sentence with an explicit reference to section 7.3.1.
of flute-revised should be sufficient.
Is there anything else?


Le 2 nov. 2011 =E0 16:13, [email protected] a =E9crit :

> =

> The  FLUTE SDP " draft-ietf-rmt-flute-sdp-01" is ready for RMT Working Gr=
oup 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 SD=
P 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 suf=
ficiently finalized version of FLUTE (soon to be submitted for publication)=
 that we are ready to move this document along.  The document was updated t=
o be consistent with the work that has been accomplished since its original=
 inception.
> =

> best regards,
> =

> Brian Adamson
> [email protected]
> =

> =

> =

> =

> =

> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rmt