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
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
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
thanks.

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-12-06)
No email
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
-- 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?

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection