Subject: [avtext] multiple-clock-rates: minor issues during proto writeup

From: Jonathan Lennox <[email-masked]>
Date: Wed, 4 Sep 2013 17:19:16 -0400

Hi --

I noticed two issues while working on the Publication Request writeup of the multiple-clock-rates draft.  (I'd like to apologize for taking so long to get to this.)

[As shepherd:]

One was caught by the I-D nits tool.  This document formally updates RFC 3550, and says so in the document header, but currently the abstract doesn't mention this fact.

It's sufficient to add a sentence "It updates RFC 3550." to the end of the Abstract. See the Internet Draft checklist <http://www.ietf.org/id-info/checklist.html> section 3.1.D for a full description of the relevant requirement.

[As individual:]

The other is a minor quibble to the terminology section.  It defines an RTP Sender as a logical network element that "receives RTCP RR packets", and an RTP Receiver as one that "sends RTCP RR packets."

This isn't quite true, since a network element can be both an RTP Sender and an RTP Receiver simultaneously. When you're both a sender and a receiver, you send RTCP reception report blocks in your SR packets, not in RR packets.

I think more accurate wording would be to say that an RTCP Sender "receives RTCP reception report blocks", and an RTCP Receiver "sends RTCP reception report blocks."

Does the WG agree to such a change, if we need to update the draft anyway to resolve the first issue?
--
Jonathan Lennox
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 5 Sep 2013 09:23:52 +0200

On 2013-09-04 23:19, Jonathan Lennox wrote:
> Hi --
> 
> I noticed two issues while working on the Publication Request writeup
> of the multiple-clock-rates draft.  (I'd like to apologize for taking
> so long to get to this.)
> 
> [As shepherd:]
> 
> One was caught by the I-D nits tool.  This document formally updates
> RFC 3550, and says so in the document header, but currently the
> abstract doesn't mention this fact.
> 
> It's sufficient to add a sentence "It updates RFC 3550." to the end
> of the Abstract. See the Internet Draft checklist
> <http://www.ietf.org/id-info/checklist.html> section 3.1.D for a full
> description of the relevant requirement.
> 
> 
> [As individual:]
> 
> The other is a minor quibble to the terminology section.  It defines
> an RTP Sender as a logical network element that "receives RTCP RR
> packets", and an RTP Receiver as one that "sends RTCP RR packets."
> 
> This isn't quite true, since a network element can be both an RTP
> Sender and an RTP Receiver simultaneously. When you're both a sender
> and a receiver, you send RTCP reception report blocks in your SR
> packets, not in RR packets.
> 
> I think more accurate wording would be to say that an RTCP Sender
> "receives RTCP reception report blocks", and an RTCP Receiver "sends
> RTCP reception report blocks."
> 
> Does the WG agree to such a change, if we need to update the draft
> anyway to resolve the first issue? -- Jonathan Lennox 
> [email-masked]

Agree that you spotted a minor shortcoming and are fine with your
suggestion.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
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: [email-masked]
----------------------------------------------------------------------

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Sep 2013 02:50:35 +0000

Make sense to me.

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Lennox
Sent: Thursday, September 05, 2013 5:19 AM
To: Marc Petit-Huguenin; Glen Zorn
Cc: [email-masked]
Subject: [avtext] multiple-clock-rates: minor issues during proto writeup

Hi --

[As shepherd:]

[As individual:]

_______________________________________________
avtext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/avtext