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

["Ali C. Begen (abegen)" <[e-mail]>]

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

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Monday, January 03, 2011 12:07 PM
> To: Dave Oran (oran)
> Cc: Ali C. Begen (abegen); [e-mail]
> Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10
> 
> 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/
> 
>