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

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

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.

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

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