Subject: [Gen-art] Gen-ART review of draft-ietf-avt-profile-savpf-11.txt

From: Ben Campbell <[email-masked]>
Date: Mon, 27 Aug 2007 13:28:52 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art