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

> >> 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.

> >> - 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/
> 
> 