Here are my Technical and Editorial comments:
T1: page 19, Section 6.1 -
The Metering Process must support inclusion of the following in
each Packet Report, as a configurable option:
(iii) a basic report on the packet, i.e., some number of
contiguous bytes from the start of the packet, including the
packet header (which includes link layer, network layer and
other encapsulation headers) and some subsequent bytes of
the packet payload.
In most cases I do not know how an IP-layer networking device like a
router can access the link layer header.
T2: page 19, Section 6.2 - The value of the DSCP field is worth being
added to (iv)
T3: page 24, Section 9 - The manageability considerations should include
not only information about how to configure the Metering Process, but
also how to configure reporting and how to monitor the status of the
observation points and of the collectors. Also, are there any alarms
situations (congested collectors for example?)
T4: Section 11.3 - for psamp-based Passive Performance Measurement to
play a role in verification of SLAs, one needs to have the basic
metering process parameters be included in the definition of the SLA and
how SLA metrics are defined and measured
T5: Section 12 Security Considerations - this section seems to me
incomplete. For example RFC 3917 describes in its corresponding Security
Considerations section the need to deal with the DoS and forgery
threats. Similar information should be included here at least by
reference - e.g. the need of authenticating collectors, protect against
mis-configuration of the metering and reporting processes, etc.
E1: The two paragraphs before the Table of Contents should be deleted
E2: The text after the Table of Comments until the start of Section 1
duplicates text on page 1 and should be deleted.
E3: Section 3.2 - 'Examples include: a line to which a probe is
attached, a shared medium, such as an Ethernet-based LAN, a single port
of a router, or a set of interfaces (physical or logical) of a router.'
- what is a 'port of a router' - is it not equivalent with a physical
interface? If so I suggest to make the terminology consistent
E4: Section 3.9 - why does the 'most generic' Metering Process include a
primitive selector. It seems to me that what is meant here is not the
'most generic' but the most simple or basic Metering Process.
E5: Section 4.2 - what means 'cognizant of privacy and anonymity
issues'?
E6: Section 5.2 - I do not like the definition of systematic count based
sampling. It would be better if it was stand-alone and not defined by
similarity with systematic time based sampling. In any case, if it based
on the later, the definition of systematic time based sampling should
come first. Then there is a typo that makes the phrase even harder to
understand s/expect / except.
E7: the list of filters for the Selection Process in Section 5.2, page
15: What do (iv) and (v) mean? Are these packets that failed Ingress
filtering as per RFC2827 (iv) and packets that were detected as out of
spec for (v)? Making this clear would help.
E8: page 18, Section 5.4 - 'The Attained Selection Fraction can be used
to estimate the number bytes present in a portion of the Observed Packet
Stream. Let b1, b2,..., bn be the bytes reported in each of the packets
that reached the Collector ...' s/number bytes/number of bytes/ and s/be
the bytes/be the number of bytes/
E9: page 24, Section 9 - s/writeable MIB module/MIB module with
writeable objects/
E10: Section 10 - The first paragraph is duplicated
E11: Section 10.2 - The first phrase in the section could be dropped
E12: Section 10.2 - Expand ASIC
Thanks and Regards,
Dan
> -----Original Message-----
> From: The IESG [mailto:iesg-secretary@xxxxxxxx]
> Sent: Monday, October 22, 2007 4:06 PM
> To: IETF-Announce
> Cc: psamp@xxxxxxxx
> Subject: Last Call: draft-ietf-psamp-framework (A Framework
> for Packet Selection and Reporting) to Informational RFC
>
> The IESG has received a request from the Packet Sampling WG
> (psamp) to consider the following document:
>
> - 'A Framework for Packet Selection and Reporting '
> <draft-ietf-psamp-framework-12.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the ietf@xxxxxxxx mailing lists by
> 2007-11-05. Exceptionally, comments may be sent to
> iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-12.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=9292&rfc_flag=0
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf