Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources
Note: This ballot was opened for revision 07 and is now closed.
(Steven Bellovin) Discuss
Discuss (2004-03-17 for -** No value found for 'p.get_dochistory.rev' **)
The suggested use of speech as a biometric authenticator over the Internet is in direct contradiction of the recommendations the cited U.S. National Research Council study . Note also the comments that biometric authenticators must be treated as static passwords when traversing a network -- they're subject to capture and replay. We do not permit use of plaintext passwords in IETF standards. I'm not (quite) prepared to insist that the material on biometrics be deleted from the specification. But I'd really like more discussion of the concerns from the report in the Security Considerations section -- a reader of just this document would have no hint that the report says flat-out that this is a bad idea. Beyond that, the document must mandate use of confidentiality technologies for such uses.
(Jon Peterson) Yes
(Bill Fenner) No Objection
(Ted Hardie) No Objection
Comment (2004-03-17 for -** No value found for 'p.get_dochistory.rev' **)
I'm a no-ob on this because I don't think it will actively harm the effort to get this work done, but there are a lot of requirements in here that aren't well mapped to specific use cases. The "VCR controls" noted in 4.5, for example make no sense for the speaker identification use case given in 2.3, but those requirements are put forward as if they applied to all use cases. This document also trends away from the requirements to the design on a number of cases (the xml:lang tag for multi-lingual TTS, for example). The acknowlegemetns are, too say the least, interesting; the rules indicating that it is a bad idea for a doc author and chair to be the same aren't there to prevent appropriate acknowledgement when it occurs--they're there to avoid conflicts in role.
(Sam Hartman) (was Discuss) No Objection
(Scott Hollenbeck) No Objection
Comment (2004-03-16 for -** No value found for 'p.get_dochistory.rev' **)
Section 3 of this document appears to be using RFC 2119 keywords, such as SHOULD, MUST, and MUST NOT, but RFC 2119 isn't cited as a normative reference. The RFC should be cited, or text should be added to the document to describe what the upper-cased keywords mean in this context.
(Russ Housley) (was Discuss, No Objection) No Objection
(David Kessens) No Objection
(Bert Wijnen) No Objection
Comment (2004-03-18 for -** No value found for 'p.get_dochistory.rev' **)
Mmm... what was that RFC-Editor policy about acronyms in titles? This doc has as title: Requirements for Distributed Control of ASR, SI/SV and TTS Resources Quite a few acronyms, no?