Hi,
thanks, Ben. A couple of quick notes (finally):
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?
This is being taken care of now. We'll have a revised document soon.
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.
They are intended as examples and they are correct. They are
multicast addresses and I am not aware of any "example ranges"
for multicast address, neither from RFC 3330 nor from 3171.
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.
Can you be more specific? Quite a few abbreviations are expanded,
several (SIP, RTSP, SAP) would be commonly known today as well.
We will be happy to expand whatever is deemed suitable (would
you consider AVP, SAVP, and AVPF to fall into this category, for
example)?
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" ?> '
Will do (but note that this is only friendly as long as the reference
is an RFC :-)
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.
Well, ok.
The following will just be addressed unless noted differently.
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?
Yes.
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.
I guess this is just a matter of aging :-)
Thanks for the catches. Will do a revision shortly as soon as
we got agreement on how to proceed with security-related aspects.
Joerg
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
