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

[Colin Perkins <[e-mail]>]

Looks good.
Colin


On 3 Jan 2011, at 16:57, David R Oran wrote:

> 
> On Jan 3, 2011, at 11:49 AM, Ali C. Begen (abegen) wrote:
> 
>>>>> 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?
>>>> 
>>>> 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.
>> 
>> 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.
>> 
> 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"
> 
> 
>>>>> - 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?
>>> 
>>> 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
>> 
>> 
>>>>> - 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
>>>> 
>>>>> --
>>>>> Colin Perkins
>>>>> http://csperkins.org/
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> Audio/Video Transport Working Group
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/avt
>>> 
>>> 
>>> 
>>> --
>>> Colin Perkins
>>> http://csperkins.org/
>>> 
>>> 
>> 
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt



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