Ben - Thanks for the review!
Joerg/Elisabetta: can you comment?
Colin
On 27 Aug 2007, at 19:28, Ben Campbell wrote:
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.
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
