Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

[stephen botzko <[e-mail]>]

I would add that it is possible that another SDO has work-in-progress that
might overlap, so it is important to ask them.  This is slightly different
from getting information on something already finished.

I agree that this particular issue is not a reason to block the formation of
the WG itself, but that the WG should be required to make the evaluation.

Stephen Botzko
Polycom

On Thu, Jan 21, 2010 at 9:28 AM, Adrian Farrel <[e-mail]>wrote:

> Richard,
>
> I think I agree...
>
>
>  It's not clear to me why SDOs need to be involved in the process of
>> determining whether existing codecs satisfy the requirements.
>>
>
> However, no-one can make the determination without requirements to make an
> evaluation against.
>
> And to be sure that all the candidates are in the melting pot, it is at
> worst harmless to poll the other SDOs for their input and suggestions.
>
> I would expect that one of the tasks of this WG is to coordinate and
> document (i.e. make) the evaluation.
>
> Cheers,
> Adrian
>
>
>  Information on standard codecs -- including their technical and legal
>> aspects -- is pretty widely available.  And if information about a  codec
>> isn't generally available (e.g., if standards are being closely  held), then
>> that codec fails to meet the requirements by definition --  there's a
>> requirement that it by widely implementable, which requires  its
>> specification to be widely available.
>>
>> I've only been following this discussion off and on, but I don't  really
>> see anyone really challenging the requirements in the current  draft
>> charter, and I don't really see anyone proposing codecs that  meet those
>> requirements. Unless one of those two changes, it seems  evident that the
>> requirements are not being satisfied, so we should  just move on with
>> forming the WG.
>>
>> --Richard
>>
>>
>>
>> On Jan 21, 2010, at 8:39 AM, Adrian Farrel wrote:
>>
>>  [snip]
>>>
>>>  What I try to say is that first the requirements must be set, only then
>>>>> will it be possible for representatives of other SDOs to determine  if
>>>>> already standarddized codecs (or codecs under standardization)  meet
>>>>> them.
>>>>>
>>>>
>>>> I agree.  Obviously no one (inside or outside the IETF) can tell exactly
>>>> how existing codecs in other SDOs relate to this work until the detailed
>>>> requirements are locked down.
>>>>
>>>> Also, I think the burden is mostly on CODEC to make this  assessment.
>>>> Other
>>>> SDOs may offer their views in liason statements, and can respond  with
>>>> their
>>>> own work programs.  But in the end it would be up the IETF to  decide if
>>>> there is too much overlap.
>>>>
>>>
>>> Right, and this is surely easy to achieve and good project  management,
>>> anyway.
>>>
>>> Document the requirements to a reasonable level of detail.
>>> Circulate the requirements explicitly requesting suggestions.
>>> Evaluate the suggestions and give reasons for rejecting existing  Codecs.
>>> Go on and develop a new Codec if required.
>>>
>>> It does not follow that people cannot start work on a new Codec  before
>>> completion of the third step, but the WG would be premature  to adopt a
>>> Codec solution draft before having formally surveyed the  landscape.
>>>
>>> The first step has to be done anyway, and I don't see that it can be
>>> considered as slowing down the development of a solution since it is
>>> impossible to build a solution without knowing the requirements. The second
>>> step might add a few weeks to the cycle. The third step, if  we are to
>>> believe the comments in this thread, will not take long.
>>>
>>> So why does anyone object to such a process?
>>>
>>> As to whether this sequence of steps should be codified in the  charter,
>>> my experience is that if you don't write down a process, it  is very hard to
>>> get interoperable implementations.
>>>
>>> Thanks,
>>> Adrian
>>>
>>>
>>> _______________________________________________
>>> Ietf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ietf
>>>
>>
>>
>>
>