Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Inline.

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Roni Even
> Sent: Wednesday, May 13, 2009 5:22 AM
> To: Bill Ver Steeg (versteb); avt at ietf.org
> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working
> group item
> 
> Bill,
> Any changes that are not editorial should be presented to the list before
> they are added to the draft.
> 
> The changes for section 8 and 13 can be added to the draft.

OK.
 
> For section 7 please send a suggestion to the list since I am not sure that
> there was a preferred way to do it.

As we proposed previously (actually since version -00), we are using TLV elements to provide the extension mechanism and avoid the problems associated with using special values in various fields. In the update, we are saying that the TLV types will be registered with IANA in a new registry. Some of the available type space is reserved for vendor-neutral extensions whereas the rest is for private extensions. We briefly outline the requirements for registering the vendor-neutral extensions.

As proposed by Ingemar previously in the breakout session, we are now using sub FMT fields to specify the individual RAMS messages (request, information and termination). So, for the message format we have something like:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    SFMT=1     |          Optional TLV-encoded Fields          |
     +-+-+-+-+-+-+-+-+                                               |
     :      Optional TLV-encoded Fields (and Padding, if needed)     :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Further RAMS message types could be defined in the future, if needed.

We wanna conclude these issues quickly and address the remaining open items (you mentioned some of them already) in the next revision.

BR,
-acbegen 

> Thanks
> Roni Even
> AVT co-chair
> 
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Bill
> Ver Steeg (versteb)
> Sent: Wednesday, May 13, 2009 3:08 PM
> To: avt at ietf.org
> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
> Sessions(RAMS) as a working group item
> 
> 
> 
> We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp".
> This is basically a name change from
> "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion
> with other pending "synchronization" drafts.
> 
> There were some issues remaining from -03 version that have already been
> identified on the list and technical breakout session. We are planning
> to address these issues in the next version of the draft.
> 
> We hope to address the following areas in the next revision of the
> draft:
> 
> - Section 7 - Define a method for vendor-specific and generic extensions
> to RAMS, lay out the intent to use FMT==6 for all messages and to have
> an (extensible) enumeration of the RAMS sub-FMTs
> - Section 8 - Elaborate SDP to describe the various use cases for RAMS
> - Section 13 - Define a single registry (FMT==6) for all RAMS
> transactions, and then define Sub-FMT Values for RAMS Messages. Also
> define an extensible RAMS TLV space registry
> 
> - We need to make some typographical corrections, mostly changing from
> RMS to RAMS.
> - We need to formalize the TLV definitions and extensions (both vendor
> and private extensions)
> - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to
> identify various RAMS messages
> - We need to clarify the SDP section based on the earlier discussion.
> The SDP example is still declarative and we are looking forward to
> include more examples as we move forward.
> - The IANA concerns section needs to be updated to reflect how to extend
> the RAMS protocol.
> - The unicast/multicast addresses need to be fixed according to the
> idnits tool.
> 
> Are there other issues that we need to address in the next revision of
> the draft? The authors would like to address these high priority issues
> in the next few days, so timely feedback would be appreciated.
> 
> 
> Bill VerSteeg
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt