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

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
>>> avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>> 
>> 
>> 
>> --
>> Colin Perkins
>> http://csperkins.org/
>> 
>> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt