Subject: [Fecframe] Comments of FECFrame Charter

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 01 Dec 2005 16:01:29 +0000

1) I know this has been raised before, but I have serious concerns about the
introduction of IPR into the IETF transport layer. I feel this is totally
inappropriate way to design IETF-specified Internet Transport.

I'd feel very much happier if this charter Explicitly identified that the
Architecture/Framework PS would itself be IPR-free. Is there some way this
can be expressed in the Charter as a drive to an OPEN framework?

2) I'm unsure about the word "considered".

Can you clarify what is meant by the goal of:
 "Other usages will be considered and prioritized,"
--- Is this within the PS?
--- ... Or the WG?
--- ... Does that mean this "other" RFCs are expected with this Charter?

3) At the moment I see the WG developing one concrete PS on a Framework.
--- presumably relating to transport over UDP, DCCP and supporting RTP/RTCP?

4) I'm a little fuzzy about the August 2007 deadline, and what exactly this
will be delivering.
--- Can you clarify a little?

Best wishes,

Gorry

_______________________________________________
Fecframe mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 02 Dec 2005 10:17:37 +0100

Hi Gorry,

Great, that someone has feedback on the charter proposal. My personal 
comments on your comments.

> can be expressed in the Charter as a drive to an OPEN framework?

I fully agree with the intention of having the framework IPR free. 
However there are issues with stating this explicitly as an requirement 
in the charter as I see it. First of all we can never guarantee that any 
solution is IPR free. Secondly, I fear that such an strict statement 
could be used to de-rail the process. I want the WG to have the 
possibility to choose if the situation arise.

Therefore I would like to keep this out of the charter. However I think 
it is a requirement for the framework solution at should strength.

However I do hope that digital fountain's updated IPR statement when it 
appear will make people more comfortable.

> --- Is this within the PS?

My intention when I wrote this was to indicate that it is up to the WG
to consider other use-cases that is brought to it. And with that I meant 
to be used in the development of the framework to enable future usage in 
those scenarios.

> --- ... Does that mean this "other" RFCs are expected with this Charter?

If you mean that it would imply that FECFrame would develop further 
specifications (RFCs) to ensure that other solutions than streaming 
media also is fully specified. Then I would say no at this point in 
time. However I think that is a reasonable extension of the WG if 
interest exist. Are there interest for text to place further 
clarifications that this is out of scope?

Lets try to clarify the first part:

A primary objective of this framework is to support FEC for streaming
media. Other potential usages of the framework may be brought to the 
working group for consideration during the development of the 
requirements, to enable future support of those usages. The group will 
coordinate closely with AVT and MMUSIC working groups to ensure that the 
streaming use-case is fully specified both in terms of interactions with 
RTP/RTCP and application layer signalling. The group will also 
coordinate with the DCCP working group, at least, considering that 
transport protocol's role in streaming media. The interactions of the 
framework with existing and used security mechanisms must also be 
considered.

Is the above text better?

> --- presumably relating to transport over UDP, DCCP and supporting RTP/RTCP?

Yes, at least one PS for the framework. I also see another PS for the 
signalling parts. It would quite likely also be a FECFrame document also 
that is reviewed in MMUSIC and AVT.

> --- Can you clarify a little?

The deliverables in this milestone would be any informational documents 
and at the latest the streaming signalling document. I foresee that we 
may like to document for history the requirements in an informational 
RFC. There might also be need to have further documents specifying the 
application of the framework for the streaming media case. This may be 
part of the signalling specification PS or a stand alone document.

It is very difficult to lay down exact document divisions at this point 
in time when only have a problem space, and no agreed requirements. 
However the above is the document I foresee could be needed.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]