It's not clear to me why SDOs need to be involved in the process of
determining whether existing codecs satisfy the requirements.
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
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf