Subject: [Gen-art] Gen-ART review of draft-ietf-psamp-framework-12

From: Ben Campbell <[email-masked]>
Date: Sun, 4 Nov 2007 21:32:48 -0600

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-psamp-framework-12
Reviewer: Ben Campbell	
Review Date:  10/4/2007
IETF LC End Date: 10/5/2007
IESG Telechat date: (if known)

Summary:

This document is almost ready for publication as in informational RFC,  
but there is a potential open issue as well as a number of nits that  
should be addressed prior to publication.

Comments:

Open Issue:

Section 12:  Security Considerations

The security consideration section seems too lightweight. It simply  
calls out some security related requirements elsewhere in the  
document, and offers no additional discussion.  It is not clear to me  
that the referenced sections described the requirements from a  
security perspective--it would be useful to describe in section 12  
_why_ those requirements are important for security, and what  
potential security issues or attacks they are intended to prevent.

More importantly, PSAMP seems to me to have lots of privacy  
implications, which the PSAMP charter appears to acknowledge with its  
mention of privacy and anonymity issues. In my opinion these warrant  
discussion in this section.

nits:

General:

There are an unusually large number of authors listed in the Author  
Addresses section.  Did all of these contribute substantial text to  
the document?

There is a lot of language which appears to me to be normative, but  
does not follow normal capitalization for normative statements. I  
realize this is an informational document, but I gather the intent is  
to define terms. The document often states that an element described  
by a term "must" have certain features or meet certain requirements.  
This feels like a place where normative language, with appropriate  
capitalization makes sense. (This interacts with a specific comment on  
section 2 below)

This document states a number of requirements that might be referenced  
by future documents. If there is any intent that other document be  
evaluated for compliance with the requirements herein, it would be  
useful to break such requirements out and number or otherwise label  
them so they can be easily referenced in other documents.

Section numbers are inconsistent in the use of a trailing period. This  
makes searching for section headings difficult.

idnits returns the following warnings:

  == Outdated reference: A later version (-08) exists of
      draft-ietf-psamp-protocol-07

   == Outdated reference: A later version (-07) exists of
      draft-ietf-psamp-info-06

   == Outdated reference: A later version (-26) exists of
      draft-ietf-ipfix-protocol-24

Abstract: Is it appropriate to give mail list information in an RFC?  
This document will live forever, and I assume the mail list will  
become obsolete some time before that.

After ToC but before section 1: There's a strange repeat of draft  
boilerplate after the ToC but before the Intro. I assume it's a  
formatting error.

Section 2, first paragraph: "Definitions of terminology and the use of  
the terms "must", "should" and "may" in this document are  
informational only."

I'm not sure what to make of this disclaimer. This document places a  
number of requirements on devices it describes. Are those not  
normative, at least in the sense that a device that does not meet  
certain requirements should not be labeled a PSAMP device, etc?

Bottom of page 9: ASCII art crosses the page boundary in a way likely  
to confuse the reader.

Section 4.4 Last Paragraph, last sentence: Comment about feasibility  
and complexity of PSAMP operation feels like a non sequitur. Why is it  
mentioned in a section about configuration?

Section 5.2: The section heading is orphaned from contents by a page  
break. This can be confusing to the reader.

Section 5.2 paragraphs 3 and 4: I suggest switching the order, since  
the first refers to the second, and there appears to be no reason to  
maintain the current order.

Section 5.2 paragraph 5: n-out-of-N sampling: While this may be a term  
of art of which I am not familiar, it's generally not a good idea to  
distinguish two variable names by case alone.

Page 15, sixth paragraph: "When the PSAMP device offers property match  
filtering..."

This paragraph has interesting implications that a PSAMP device may  
have other purposes other than metering, e.g. it may also be a router,  
etc. While this may seem obvious to the writers, it may not to all  
readers. I suggest explicitly mentioning that in the definition of  
PSAMP device in section 3. Also, since the next few paragraphs talk  
about how routers should expose information for PSAMP purposes, a  
separate subsection talking specifically about routers acting as PSAMP  
devices might be helpful.

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