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

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Sep 2007 14:04:42 +0100

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Joerg Ott <[email-masked]>
Date: Tue, 04 Sep 2007 16:08:01 +0300

On my list.  But not before next week (too many reviews in progress).

Joerg

>> I am concerned about some SHOULD strength normative requirements  that 
>> have security implications.  Did the Working Group discuss  whether 
>> examples of scenarios where one might want to violate the  requirements?
>>
>> 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:
>>
>> 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:
>>
>> 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:
>>