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 <[email protected]>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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> >> >> >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
