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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 30 Dec 2007 10:41:07 +0100

It is not clear to me whether the issues raised in the Gen-Art review
were addressed. I would suggest that the editors provide an answer to
all issues raised in Ben's review before we submit this document to the
IESG. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Albert Greenberg [mailto:[email-masked]] 
> Sent: Monday, November 05, 2007 9:30 AM
> To: Ben Campbell; General Area Review Team
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; Romascanu, Dan (Dan); [email-masked]
> Subject: RE: Gen-ART review of draft-ietf-psamp-framework-12
> 
> HI Ben,  Thanks!  I see psamp security considerations as 
> somewhat similar to those in ipfix, as was noted in Section 
> 4.3.   This discussion can be clarified and improved in the 
> document.   Regards, Albert
> 
> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Sunday, November 04, 2007 7:33 PM
> To: General Area Review Team
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Albert 
> Greenberg; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Gen-ART review of draft-ietf-psamp-framework-12
> 
> 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

---

From: Albert Greenberg <[email-masked]>
Date: Sun, 30 Dec 2007 09:13:02 -0800

Hi Dan,

I'll get back to you on this in the next days.

Regards, Albert
________________________________________
From: Romascanu, Dan (Dan) [[email-masked]]
Sent: Sunday, December 30, 2007 1:41 AM
To: Albert Greenberg; Ben Campbell; General Area Review Team
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Gen-ART review of draft-ietf-psamp-framework-12

Thanks and Regards,

Dan