Hi Magnus, We are all glad to have you back. Comments are inline. We will get these into the revision. See inline. > I have the following comments on this document, I think version 7 or 8 > was the last version I read before my parental leave. > > > 1. Applicability statement: I think this document should have an > applicability statement making clear that this is only for engineered > environments due to the traffic bursts. We already put a lot of effort to explain the precautions for using this in BE networks. I don't think there is a strong argument here that this will only work in engineered networks. So, personally I don't think we should put such a statement. > 2. Section 6.2, bullet 5: I don't think the document is clear on that > the BRS is expected to determine if a RAMS-R is a retransmission or an > update based on if any content of the message has been changed. The statement over there implies this. And naturally it is the server's job to figure that out. Based on this discussion, we even wrote the new CNAME guidelines document so that the server's job would get easier. > 3. I worried that what is intended to be an RAMS-R update from the > client will be interpreted as new RAMS-R request. The reason is the only > that separates these two cases are timing, does it arrive before the > burst ends or not. Relying on this heuristics is quite weak and error > prone. I still wished that an sequence number had been added to RAMS-R. I gave enough arguments why we should not use a seqnum for the RAMS-R messages earlier. It is not justified IMO. Based on the SSRC of the primary and the requesting client's CNAME, things are pretty straightforward. > 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globally > unique CNAME identifier." > > I don't think this is a statement that can either be fulfilled nor > tested. You can mandate a method for selecting CNAMEs that has low risk > of producing CNAME collisions, but nothing can guarantee it unless a > entity is coordinating the CNAME space for all clients. Can you mandate > the method instead? The new CNAME draft has ways to ensure they are unique. If the client uses one of them, we are all set. > If I understand the impact of a CNAME collision is that the collision > clients request will be mixed up, for example terminating each others > request, or update the values in the RAMS-R. When they are unique, this won't happen. > 5. Section 6.4 and others: The draft has a tendency of formulating > itself as everything is guaranteed to work as long as one keep within > given limits for bandwidth etc. An example from Section 7.2 Max Receive > Bitrate TLV: We don't assume things will sure work or guarantee that they will work if everything is satisfied. These are simple rules that both sides must comply with. > If specified, the total bitrate of the unicast burst(s) plus any > payload-specific information MUST NOT be larger than this value. > Otherwise, congestion and packet loss may occur. > > The last sentence I would formulate as: > "Otherwise, congestion and packet loss are much likelier to occur" How about "more likely to occur"? > Even if one stays within this value congestion and packet loss may > occur. This is not the only case, but when I actually decided this seems > to be an issue, I hadn't taken note of all examples I seen. > > 6. Section 7: > > Each feedback message has a fixed-length field for version, padding, > feedback message type (FMT), payload type (PT), length, SSRC of > packet sender, SSRC of media sender as well as a variable-length > field for feedback control information (FCI). > > > What is called "Payload type" is actually "Packet Type" in RTCP packet > headers. We followed the definition from 4585 but "packet type" makes more sense to me as well. > 7. Section 7.3: > "The MSN value SHALL > be set to zero only when a new RAMS request is received." > > How is that actually known? And why reset it at all? Why not increase if > for each new RAMS-I message with new content, independently if it is an > update or a new request. If this is relating to a new burst request, then it is reset. Ow, what is the point of having a seqnum? If something has changed compared to the previous RAMS-I, then MSN is incremented. If it is just a re-xmit, MSN stays the same. > 8. Section 7.3: > "When the RTP_Rx receives a RAMS-I message with a response code > that it does not understand, the RTP_Rx MUST send a RAMS-T message > immediately to the BRS." > > Which media sender SSRC should the client direct this request to if it > hasn't been signalled in SDP nor any RTP/RTCP packets received? The rules in the RAMS-T section applies. You received a RAMS-I so you know the SSRC. > 9. Section 7.3, Media Sender SSRC TLV: > " While this > information is already available in the message header, it can be > useful to repeat it in an explicit field." > > This sentence seems out of place compared to the rest of the text. If I recall correctly, this was something you asked for. I am not sure whether there is a better place to put it. Maybe in parentheses? > 10. Section 7.3, RTP Seqnum of the First Packet TLV: > > How is this TLV bound to the SSRC number if is for? This is not > explicitly explained. What do you mean? The SSRC comes from the RAMS-I's SSRC. There is one (not multiple) stream per RAMS-I. > 11. Section 7.4: > Each of these RAMS-T messages has > the appropriate media sender SSRC populated in its message header. > > Instead of writing "appropriate" cant you simply write " Each of these > RAMS-T message's media sender SSRC SHALL BE populated with the SSRC of > the Media Stream to be terminated." Good suggestion. > 12. Section 8.3: > "This section provides a declarative SDP [RFC4566] example for > enabling rapid acquisition of multicast RTP sessions." > > Can you make clear that this an example of an SDP to be provided to a > client? OK. > 13. Section 9, bullet b: > Be configured to forward certain ports (e.g., using HTML > configuration and UPnP IGD [UPnP-IGD]). > > Shouldn't the "and" be an "or"? Yes, good catch. > 14. Section 10: > > Shouldn't the security consideration make it clear that RAMS-R are > especially suspectible to Replay attacks as there is no information in > the packet that one can use to detect that it is out of sequence. There is a wording about this in that section (which simply refers the reader to 5760). Are you considering a RAMS-specific replay attack here? > Cheers > > Magnus Westerlund Thanks much for the detailed review. Cheers, acbegen. > ---------------------------------------------------------------------- > 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: magnus.westerlund@xxxxxxxxxxxx > ---------------------------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf