Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Jan 2011 14:21:35 +0000

Ali,

On 21 Dec 2010, at 07:10, Ali C. Begen (abegen) wrote:
> This revision includes the changes we agreed on in the last week's call and after the feedback on the list. It also addresses Glen's comments, makes some clarifications here and there.

This is looking good. Some minor comments only:

- Section 3:  “Therefore, the server will need the client to also include the Token along with the RTCP messages that are different from the RTCP message that triggerred the unicast session establishment.” - I don’t understand what this means. Can you clarify in the draft?

- Section 4.1: “Here, the SSRC value is not necessarily linked to the one used by the client in the multicast session.” - what do you mean by “not necessarily” here? They’re either part of the same RTP session, in which case the client should use the same SSRC; or they’re not, in which case the client should choose its SSRC randomly.

- Section 4.2: The addition of the packet types element is good. However, for clarify, it would be useful to include a packet diagram showing the format of such an element with enough entries to fill more than one 32 bit block and require padding to the next.

- Figure 6: “PT of request” - the RTCP packet that causes this respond to be generated might not be a request to the server. This field might be clearer called “Failed PT”?

I didn't look at the SDP sections, sorry.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 3 Jan 2011 08:24:36 -0800

Hi Colin,

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Monday, January 03, 2011 9:22 AM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10
> 
> Ali,
> 
> > This revision includes the changes we agreed on in the last week's call and after the feedback on the list. It also addresses
> Glen's comments, makes some clarifications here and there.
> 
> 
> - Section 3:  “Therefore, the server will need the client to also include the Token along with the RTCP messages that are
> different from the RTCP message that triggerred the unicast session establishment.” - I don’t understand what this means.
> Can you clarify in the draft?

Certain messages don’t establish a unicast session but control it, and they can be required to be bundled with a token as well as described in 4.3.1.
 
> - Section 4.1: “Here, the SSRC value is not necessarily linked to the one used by the client in the multicast session.” - what do
> you mean by “not necessarily” here? They’re either part of the same RTP session, in which case the client should use the
> same SSRC; or they’re not, in which case the client should choose its SSRC randomly.

When requesting a Token, the SSRC used or chosen by the client does not matter. Think about a client requesting a token during booting. It can use that token with any ssm session later on. We could say "Here the SSRC value can be chosen randomly by the client since the Port Mapping Request message is not necessarily linked to a specific multicast session."

Is this better?
 
> - Section 4.2: The addition of the packet types element is good. However, for clarify, it would be useful to include a packet
> diagram showing the format of such an element with enough entries to fill more than one 32 bit block and require padding
> to the next.

OK, I will give it a shot.
 
> - Figure 6: “PT of request” - the RTCP packet that causes this respond to be generated might not be a request to the server.
> This field might be clearer called “Failed PT”?

Sounds good.
 
> I didn't look at the SDP sections, sorry.

Thanks anyway.
-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Jan 2011 16:40:53 +0000

Hi Ali,

> Certain messages don’t establish a unicast session but control it, and they can be required to be bundled with a token as well as described in 4.3.1.

Sure, I understand that. But the text in the draft is unclear, and needs updating.

> When requesting a Token, the SSRC used or chosen by the client does not matter. Think about a client requesting a token during booting. It can use that token with any ssm session later on. We could…

Not really, since it's just as vague. Saying the SSRC "can" be chosen randomly doesn't help: either it is chosen randomly, or it isn't. Which is it?

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 3 Jan 2011 08:49:38 -0800

> Sure, I understand that. But the text in the draft is unclear, and needs updating.

What about:

   During the unicast session lifetime, client's certain actions and
   messages sent by the client might need to be authorized by the server by
   requiring a valid Token.  Therefore, the client needs
   to also include the Token along with such RTCP messages. 
   These are explained later in this document.
 
> > When requesting a Token, the SSRC used or chosen by the client does not matter. Think about a client requesting a token
> during booting. It can use that token with any ssm session later on. We could say "Here the SSRC value can be chosen
> randomly by the client since the Port Mapping Request message is not necessarily linked to a specific multicast session."
> >
> > Is this better?
> 

"Is chosen" then. I was reluctant to say this explicitly since a client who asks for a token right on the instant it needed one could still use the SSRC from the multicast session if it wants to. But, doing so will not break anything.

-acbegen

---

From: David R Oran <[email-masked]>
Date: Mon, 3 Jan 2011 11:57:10 -0500

>   These are explained later in this document.
How about some word-smithing:
"During the lifetime of a unicast session, a client may need to send RTCP messages that require server authorization. Since such messages require a valid Token for authorization, the client needs to include the token along with such RTCP messages as explained in detail in later sections of the document"

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Jan 2011 17:06:42 +0000

Looks good.
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 4 Jan 2011 12:45:56 -0800

I asked the chairs yesterday when they will start WGLC. Just before they do that we will submit a revision to address these minor changes.

Chairs, please provide a timeline.

-acbegen

> Sent: Monday, January 03, 2011 12:07 PM
> To: Dave Oran (oran)
> Cc: Ali C. Begen (abegen); [email-masked]
> > "During the lifetime of a unicast session, a client may need to send RTCP messages that require server authorization. Since
> such messages require a valid Token for authorization, the client needs to include the token along with such RTCP messages
> as explained in detail in later sections of the document"
> >
> >
> >>>>> - Section 4.1: “Here, the SSRC value is not necessarily linked to the one used by the client in the multicast session.” -
> what
> >>> do
> >>> Not really, since it's just as vague. Saying the SSRC "can" be chosen randomly doesn't help: either it is chosen randomly,
> or it
> >>> isn't. Which is it?
> >>
> >> "Is chosen" then. I was reluctant to say this explicitly since a client who asks for a token right on the instant it needed one
> could still use the SSRC from the multicast session if it wants to. But, doing so will not break anything.
> >>
> >> -acbegen
> >>
> >>