Document: draft-ietf-avt-profile-savpf-11.txt
Reviewer: Ben Campbell
Review Date: 27-August 2007
IETF LC End Date: 2007-08-31

Summary:

This document is almost ready for publication, but has an open issue.

I am concerned about some SHOULD strength normative requirements that have 
security implications.  Did the Working Group discuss whether these should be 
"SHOULDs" or "MUSTs"? If so, is it possible to capture the motivation for using 
SHOULD in this document, or give examples of scenarios where one might want to 
violate the requirements?

There are additional editorial nits detailed in the comments.

Comments

Substantive:

Section 3.3.1, general:

This section has number of security related "SHOULD" statements that are offered 
without guidance as to when one might reasonably choose not to follow them. 
Did the Working Group discuss whether these should be "SHOULDs" or "MUSTs"? 
If so, is it possible to capture the motivation for using SHOULD in this document, 
or give examples of scenarios where one might want to violate the requirements? 
For example, if an offerer offers both a secure and unsecure alternative, and 
the answerer supports the secure version, why might it ever want to choose 
the unsecure one?

Editorial:

General:

Please state the intended status of the specification.

idnits complains that there are two occurances of IP addresses that do not 
follow the RFC 3330 rules for example IP addresses. If they are intended as 
examples, they should be adjusted.

Please expand all acronyms on first mention. There may be some acronyms that are
 so common in this community where this is not necessary (e.g. TCP), but I don't
 think this is the case for the majority of acronyms in this draft.

Please avoid constructs like "...as described in [1]." The form "...as described 
in RFC XXXX [1]" is much more friendly to readers, who will thank you for not 
making them continuously flip back to the reference sections. If you are using 
xml2rfc, it may be helpful to include '<?rfc symrefs="yes" ?> '

Abstract:

The Abstract is a little confusing. The language " is defined" and "is specificed" 
makes it hard to tell if you meant to say these are define _elsewhere_, or 
in _this_ document. A sentence or two about the value of defining how to combine 
the profiles would be helpful.

Section 1, paragraph 1:

The text mentions the Real-time Transport Protocol, but gives the acronym of 
"RTP/RTCP". An expansion of RTCP would be helpful.

Section 1.1, paragraph 5

Sentence fragment: "Or the media session will be rejected."

Section 3.3, paragraph 1:

Should there be an informational reference for SIP?


Section 3.3.1, paragraph 3:

s/answered/answerer ?

Section 3.3.1, paragraph 4, last sentence:

"Care should be taken" seems vague. What sort of care? Does this refer back to 
earlier statements in the same paragraph? Statements in the subsequent paragraphs? 
Something else? (Also, there is a spurious period at the end of the sentence.)

Section 5, paragraph 5:

I had difficulty following this sentence. Consider putting the condition ("when 2^48...")
 first, as it is necessary to understand the context of the prior part.


Reference 3: No RFC number listed. RFC 4585?

Reference 14: A newer version of the referenced draft exists.