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

[Vincent Roca <[e-mail]>]

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:
   "It is useful for describing more than one FLUTE session in
   an SDP instance and so its general use and support in SDP are
   OPTIONAL."

No, this is not "useful". This is REQUIRED. And in that case
the sender should be sure that all receiver do support this
CS mechanism. What is OPTIONAL is the use of the CS mechanism.
When there is a risk that at least one receiver may not support
it, then the sender must refrain from using it and revert to 
multiple SDP instances. 
IMHO you should remove (or clarify) the above sentence.


** Section 3.4.  Transport Session Identifier:
It is said:
   "TSI reuse is NOT RECOMMENDED whenever possible (thus, making "large time"
   unbounded regarding TSI reuse)."
Well, with a 16-bit TSI field (a possible field size), an
active server will have no other choice than reusing this
value, sooner or later. This recommendation does not seem
realistic to me.

Why not saying that:
   "TSI reuse SHOULD NOT (or probably MUST NOT, TBC) happen
   before 30 minutes, and it is RECOMMENDED not to reuse it
   before a much longer duration".


** Section 3.5. "Session Timing Parameters"
Are there good reasons to require that SDP descriptions include
a start and end time? I agree that having a "start time" is good
practice. 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 requirement on
time synchronization is strange!


** Section 3.6.1. "Number of Channels"
There are two ways to determine the number of channels, and the
I-D says that in some cases (e.g. automatic or manual editing)
there may be a difference.
However the document does not provide clear recommendations on
how to address such situations. Should a receiver give up?
Should a receiver trust the "flute-ch" attribute if present?
Something else?


** Section 3.6.2. "Destination IP Address and Port Number for Channels"
It is said:
   "When more than one channel is used in a multicast FLUTE session, it
   is RECOMMENDED that the channels are differentiated based on
   destination IP address, and channels are not differentiated based on
   destination port"
The previous section mentions unique {dest IP addr; dest port number} pairs.
Recommending that only the dest IP be considered raises the risk that
a bad implementation considers only the destination IP to differentiate
channels. It seems dangerous.
I understand the rational (congestion control with multicast group
join/leave operations) though.

Later, in the same section:
   "In the case (always with a unicast session) where the same
   destination IP address is used for all the channels of the session..."
This is wrong to say it is **always with a unicast session**, since
using different destination IP is only RECOMMENDED, not REQUIRED.


** Section 3.7. "FEC Object Transmission Information"
There is a paragraph dedicated to Congestion Control 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.
- 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 3.10. "Bandwidth Specification"
Can you say a few things about Congestion Control (CC)?
Having only the peak data rate is not sufficient for a receiver.
Having the capability, because CC is used, to receive data from
that FLUTE session at a much lower rate, thanks to CC, is an
important piece of information.


** Section 5. "Security Considerations":
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.
"Attacks against the Session Description" of flute-revised
should be sufficient.

Is there anything else (e.g. is a replay attack an issue)?