[RTW] WG charter, take 4

[Silvia Pfeiffer]

I agree with basically all of these things. More concrete comments below.


On Sat, Feb 26, 2011 at 2:01 AM, Magnus Westerlund
<magnus.westerlund at ericsson.com> wrote:
> Hi,
>
> Sorry for not having produced these charter comments earlier as most
> would apply to earlier versions also. However, I do have a number of
> comments on it and think the charter could be restructured to become a
> much better charter. But lets start with the different comments.
>
> The most fundamental issue with the charter is that it contains to much
> technical solution candidates, rather than talking about the goals and
> and general direction for achieving them. I think one needs to extract
> the few higher level goals from this list and work them into the charter
> in other ways. Certain things we likely can select, like RTP. But there
> is clearly a question on what profile and extensions that should be
> supported.
>
> I also think one of the biggest uncertainties and fuzziness in the
> charter is because the model isn't agreed on. The discussion about the
> session management is clear due to that the model for the work aren't
> agreed on. I see two ways here. Either we manage to lock down the model
> prior to the chartering, or we have a charter that included this model
> discussion. Frankly I see the later as most likely as agreement on the
> model will require agreement with IETF's partner in this work. Thus the
> charter should take a bit more height for having such model discussion.
>
> It is already obvious that any codec selection for this is going to be a
> difficult and possibly take time. To avoid this from de-railing the
> truly fundamental parts of the RTC-WEB solution, I am suggesting that
> this should be taken in its own WG, or if not possible at least as a
> separate WG item, with its own deadlines, so that it doesn't hold up
> the main work. That is likely anyway a good idea for long term purpose,
> so that only the codec selection part can be updated, and not the
> fundamental part when the set of codecs become out-dated.

I had already lost interest in this group because I thought it would
just end up in endless baseline codec discussions. I agree with
removing the baseline codec from the charter, if only to enable the
group to move forward at all.

I am not sure I agree though with creating a separate WG for it.

Instead I think it would make much more sense to accept that we will
always have a heterogeneous codec world and create a simple codec
negotiation protocol.


> I still don't understand the diffserv based QoS. This seems very
> unrealistic to be usable from a web-browser perspective. This as no
> device in any setting other than being an ISP controlled device is
> likely to be allowed to set DSCP. I think QoS can be excluded at this
> stage completely. Especially as there are a lack of methods for
> providing end-point devices with a traffic class to DSCP mapping valid
> in the currently attached network.
>
> The charter could also be clearer on the need for basic datagram and
> byte stream functionality between two peers. The higher motivation for
> it is there, but not requirements. Where I see rate control and
> security of those channels being the most important ones.
>
> I am also missing a clear requirement for enabling future extensions of
> functionality of the RTC-WEB components in the browser.

That was another key issue I also have with the charter - I was under
the impression the group is there to solve the RTC communication on
the Web (!), i.e. in Web browsers using HTML5 and HTTP. The charter
is, however, so much wider and I am starting to wonder if we are
trying to create an unwieldy solution to an unclear problem.


> I see this as
> important as we can hopefully arrive at the basic functionality
> reasonably quick, but there will be certain set of functionalities that
> are desirable but not quickly arrived agreed upon and specified. We need
> a method for enabling introduction of these in the future.
>
> I also think one can clarify the last deliverable to actually be
> requirements on signaling and the API. Different functionalities will
> have different requirements when it comes to data objects needing
> exchange and also how the negotiation between the peers happens.
>
> I am also missing a clearer requirement in ensuring that this becomes a
> network friendly traffic source. There is clearly need for congestion
> control and media adaptation as part of the basic solution.
>
> As have been raised security is an important part of this work. I think
> we need to ensure that the WG first establish a security model, and then
> follows it in development. I fully agree that there should be no
> separate documents, this should be part of the general architecture, as
> it is such a fundamental part.
>
> I am willing to provide an alternative charter proposal, if there is
> interest, attempting to take these comments into consideration.

I actually think that would be a good idea.

Cheers,
Silvia.


> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>