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

From: Joerg Ott <[email-masked]>
Date: Thu, 18 Oct 2007 17:45:06 +0300

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