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

[Roni Even <Even.roni at huawei.com>]

Hi Ali,
I would like to see the text about this extensions mechanism. It was not
discussed in the mailing list, what was done in a un-official design team or
breakout session is not binding for a WG document.

If you have a proposal please bring it forward.
It should address the issue of what extensions are allowed, what is the
registration procedure for the two types of extensions , do you need a draft
describing the extension and so on.
It should be discussed before it is added to a working group document.

Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen at cisco.com] 
Sent: Thursday, May 14, 2009 2:36 AM
To: Roni Even; Bill Ver Steeg (versteb); avt at ietf.org
Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP
Sessions(RAMS) as a working group item

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