Hi, sorry for the delayed response. Comments inline. (If I don't
comment on something, please consider this an "okay").
On Jan 16, 2008, at 5:09 AM, Benoit Claise wrote:
Hi Ben,
Thanks for your review.
See inline.
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.
We're still discussing this issue amongst ourselves, and we will
come back to you on this specific issue.
Let me address all the other issues in this email.
[...]
This document states a number of requirements that might be
referenced by future documents.
Could you please give us an example.
Pretty much every bullet item in section 4 and its subsections.
[...]
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?
See my answer above. We did this to be inline with IPFIX
architecture draft.
Okay.
[...]
Section 5.2: The section heading is orphaned from contents by a
page break. This can be confusing to the reader.
Should be corrected with a new version of the draft.
Anyway, this would be taken care of by the RFC-editor.
Never hurts to make their job easier :-)
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.
I would like to keep the order because they appear in the method
numerical order (see the IPFIX-PROTO).
However, I agree the text should be changed.
OLD:
* systematic count based sampling: similar to systematic time
based expect that selection is reckoned with respect to packet
count rather than time. Packet selection is triggered
periodically by packet count, a number of successive packets
being selected subsequent to each trigger.
* systematic time based sampling: packet selection is triggered
at periodic instants separated by a time called the spacing.
All packets that arrive within a certain time of the trigger
(called the interval length) are selected.
NEW
* systematic count based sampling: packet selection is triggered
periodically by packet count, a number of successive packets
being selected subsequent to each trigger.
* systematic time based sampling: similar to systematic count
based expect that selection is reckoned with respect to time
rather than count. Packet selection is triggered
at periodic instants separated by a time called the spacing.
All packets that arrive within a certain time of the trigger
(called the interval length) are selected.
That helps, thanks.
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.
I agree on the principle. However, n-out-of-N is the term used for
years in the sampling world.
Okay-- I can live with it if it's a term of art.
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.
I'm not sure I understand your comment, as the PSAMP device
definition speaks about the router.
3.7 PSAMP Device
A PSAMP Device is a device hosting at least an Observation
Point,
a Selection Process and an Exporting Process. Typically,
corresponding Observation Point(s), Selection Process(es) and
Exporting Process(es) are co-located at this device, for example
at a router.
Here is a proposal anyway
OLD:
When the PSAMP Device offers property match filtering, and, in
its usual capacity other than in performing PSAMP functions,
identifies or processes information from IP, transport or
encapsulation protocols, then the information should be made
available for filtering. For example, when a PSAMP Device
routes based on destination IP address, that field should be
made available for filtering. Conversely, a PSAMP Device that
does not route is not expected to be able to locate an IP
address within a packet, or make it available for Filtering,
although it may do so.
NEW:
When the PSAMP Device offers property match filtering, and, in
its usual capacity other than in performing PSAMP functions,
identifies or processes information from IP, transport or
encapsulation protocols, then the information should be made
available for filtering. For example, when the PSAMP Device
is a router that routes based on destination IP address,
that field should be
made available for filtering. Conversely, a PSAMP Device that
does not route is not expected to be able to locate an IP
address within a packet, or make it available for Filtering,
although it may do so.
That helps, thanks.
Please let us know whether your comments are addressed.
I think so, with the exception of the known open item concerning
privacy implications, and the clarification around which requirements
I was referring to with my comment about numbering the requirements.
Thanks!
Ben.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
