High-Level Requirements for Internet Voice Mail
draft-ietf-vpim-ivm-goals-06

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART.
Complete review available from
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-vpim-ivm-goals-06-dawkins.txt

This could very easily have been a DISCUSS. But the -ivm document is completed, so this document is "documenting the thinking of the group" rather than telling other people what the requirements are. That limits the value of making the goals document better.

High points:

The biggest "open issue" is that this requirements document has some
really vague "MUSTs" that need to be spelled out in more detail. For
example, "and MUST gracefully handle the case where a legacy receiving
system does not support the IVM codecs" - if the working group is
going to use this document as a filter for proposals that don't meet
the MUSTs, how would anyone know whether a proposal meets this MUST?

In general, the requirements that include the words "specifically,
this includes" are fine. It's the ones that don't include these words
that have problems!

My impression is that most of the people who have provided comments on
the draft probably understand the context, which is fine for the
working group but not-so-fine for reviewers outside the working group.

[Ballot discuss]
This is a borderline DISCUSS. I'd like to give the WG a chance to respond to Spencer's comments.

From Spencer:

The biggest "open issue" is that this requirements document has some
really vague "MUSTs" that need to be spelled out in more detail. For
example, "and MUST gracefully handle the case where a legacy receiving
system does not support the IVM codecs" - if the working group is
going to use this document as a filter for proposals that don't meet
the MUSTs, how would anyone know whether a proposal meets this MUST?

In general, the requirements that include the words "specifically,
this includes" are fine. It's the ones that don't include these words
that have problems!

My impression is that most of the people who have provided comments on
the draft probably understand the context, which is fine for the
working group but not-so-fine for reviewers outside the working group.

The document has no security considerations.  At a minimum, the IESG  expected it to say that authenticated and/or encrypted voice
messages must be supported.

This document calls for mandatory support for WAV encapsulation but this was dropped in the actual IVM specification. The discussion of WAV support therefore needs to be removed. Additionally, this document makes VPIMv2 codec a SHOULD while in the actual IVM document it is only a MAY; this also needs to be aligned.

AD review comments:

The VPIM acryonym needs to be expanded in the abstract.

References need to be split into normative and informative groups.

The [CODES] reference should be updated to point at RFC 3463.