Duplication Delay Attribute in the Session Description Protocol
RFC 7197
Note: This ballot was opened for revision 02 and is now closed.
(Gonzalo Camarillo) Yes
(Ted Lemon) Yes
(Jari Arkko) No Objection
(Richard Barnes) No Objection
Comment (2013-11-19 for -02)
No email
send info
send info
Section 1: "Furthermore, delayed duplication must not be used in cases where the primary cause of packet loss is congestion" Like Benoit, I agree that this sentence is confusing. Do you really mean something like the following? """ Delayed duplication (or duplication at all) is harmful in cases where the primary cause of packet loss is congestion, rather than network than a network outage due to a temporary link or network element failure. Duplication should only be used by endpoints that want to protect against network failures; protection against congestion must be achieved through other means. """
(Stewart Bryant) (was Discuss) No Objection
Comment (2014-01-20)
No email
send info
send info
Thank you for addressing my concern. Within the new text, "Lucky13" does not have a reference and I think it needs one (or that second example in the sentence being removed).
(Benoît Claise) (was Discuss) No Objection
Comment (2013-12-16)
No email
send info
send info
thanks.
(Spencer Dawkins) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
Comment (2013-12-06)
No email
send info
send info
Thanks for handling my discuss. I think you need a reference for Lucky13 - see [1] where'll you'll find that. [1] http://www.isg.rhul.ac.uk/tls/Lucky13.html ---- old comments below, I didn't check them - The ABNF allows for infinite numbers of delays and infinitely large delays. Wouldn't it be better to limit both? - The fact that "a=duplication-delay: 50 100" means that the 2nd re-tx is 150 ms after the initial tx is only explained in the 2nd example and you never say that otherwise. That could lead to interop problems since my initial assumption would have been that the 2nd re-tx would be 100ms after the initial tx for the above example. I think you should say something about that in section 3. - What if the delay indicated is less than a packet, say if every packet has 20ms of media but 5ms is indicated in the SDP?
(Brian Haberman) No Objection
Barry Leiba No Objection
Comment (2013-11-15 for -02)
No email
send info
send info
-- Section 3 -- Where does the new ABNF production, "delaying-attribute", fit into other ABNF? Should this be extending an existing ABNF element to add "delaying-attribute" as a new possible value (from a formal ABNF point of view)? Is a dupliation delay of 0 semantically valid?