[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
repost of accounting comments
- To: email@example.com
- Subject: repost of accounting comments
- From: firstname.lastname@example.org (John Scharber)
- Date: Fri, 10 Nov 2000 10:45:20 -0800
- Delivery-date: Fri, 10 Nov 2000 10:57:08 -0800
- Envelope-to: email@example.com
Sorry I thought this made it out on Monday but it appears the post
Accounting draft Comments
1) Specific proposal does not address what type of transaction is being
captured. Possible transactions might include:
- a) Request
Each on of these is likely to be a separate billable event that needs to
2) Records should indicate some level of QoS to indicate the quality that
was actually delivered as part of performing the transaction.
- a) Peak
3) Content ID does not necessarily need to be a URL, ala URN
4) May need to include a Content Owner attribute
5) What are the assumptions about where this data is collect and at what
level of granularity. Has any consideration been given to the Data
Life Cycle which will affect how much data is collect at which point
(i.e. which attributes are important to know at which point in the
collection process). Need to identify the interval at which data
will be collected. Also how is data reduction accomplished, what
can be aggregated, what can be compressed, etc.
Also need to consider what happens when there are multiple collection
points in a network consisting of 1+n layers, where collection can occur
on more than one layer
to extend the attributes to deal in billing across adjacent providers,
including the point of transaction and providers involved.
to identify block list for with reporting (more stat than
does the architecture deal with denial of service attacks, overload
conditions. How is this information dealt with in the accounting
data, and what provisions are made for using alternate rules sets during
this period. Should you be able to prioritize rules sets or have
alternate rule sets that are used once a high water mark is
attributes are gathered to support traffic planning activities such as
node, interface, or port.
How does the data provide for confidentiality, Data integrity
Need to define the roles of collectors of this information and
assumptions about them
I think the assumption is that, this data represents application level
detail not flow, we should state that.
Need to be able to track what device this data was read from and
who read the data
Need attribute to identify what device this service was rendered on
What is the plan for dealing with redundant readers of accounting data
and recovery from failed states.
What is used to identify the client for billing, IP addresses will be a
problem because of dynamic allocation and NATs.
Need to be sensitive to transaction durations impact on who and when data
is collected including transaction that span billing periods.
Suggest we look at the use of rolling counters and defined in RTFM as a
more stable means for storing and recovering information
If rule sets are used to define collection we should specify how rule set
matching occurs, including ordering and multiple match conditions.
Need attributes / messages to allow trace of transaction and reporting
flow for diagnostics and auditing support
May also need to use the notation of group attributes to track running
averages as opposed to being/end state information