Hi Dan, I'll get back to you on this in the next days.
Regards, Albert ________________________________________ From: Romascanu, Dan (Dan) [EMAIL PROTECTED] Sent: Sunday, December 30, 2007 1:41 AM To: Albert Greenberg; Ben Campbell; General Area Review Team Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Gen-ART review of draft-ietf-psamp-framework-12 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 PROTECTED] > Sent: Monday, November 05, 2007 9:30 AM > To: Ben Campbell; General Area Review Team > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Romascanu, Dan (Dan); [EMAIL PROTECTED] > 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 PROTECTED] > Sent: Sunday, November 04, 2007 7:33 PM > To: General Area Review Team > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Albert > Greenberg; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > 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 protected] https://www1.ietf.org/mailman/listinfo/gen-art
