Subject: Re: [Ieprep] requirements document(s) (Accounting)

From: [email-masked]
Date: Fri, 11 Oct 2002 13:51:43 EDT

In a message dated 10/11/2002 12:51:08 PM Eastern Standard Time, 
[email-masked] writes:

> You have misread my comments twice so far.
> 
> I think the problem is that you are thinking about telephony calls and SIP,
> which I was not (and am not) talking about.  I'm talking about labels in the
> context of the general requirements document from Carlberg & Atkinson.
> 
> In any event, my comments were NOT about billing -- so if you think they
> are, then you aren't reading what I wrote.  And given your track record of
> problems understanding others words also, I'm now at a loss for words on how
> to help you understand what I wrote.  Terribly sorry.
> 

Ran,

I really don't understand what you're getting so upset about and why you're 
resorting to such nasty statements. They have no place on this e-mail list.

I hope we're not referring to a different set of your comments, which your 
statement above about me misreading it twice would imply. The text from your 
e-mail of Oct 11 is the following:
------------------------------------------------------------------------------

-----------------------------------

    A service provider might offer "routine" and "preferred" service using 
DiffServ
for packet marketing.  It likely will charge on a flat-rate basis for this,
with a customer falling into one of two categories:
        routine-only service
        routine-or-preferred service

    In this case, it would be up to the end-user to mark the DiffServ bits
correctly prior to the packet arriving at the service provider.  And
the service provider would probably merely configure the edge device
to re-write the DiffServ bits to "routine" for all customers having the
routine-only service offering.  Existing network equipment often has
this capability because this is what IP service providers have been 
asking for over the past few years.

    I'll observe that today nearly all IP service providers primarily offer
flat-rate billing.  The next most common method (far less common than flat 
rate)
is to count the sum of the traffic moving through an interface over some unit 
of time
and charge based on a percentile (often 90 percentile) of that traffic count.
Most IP service providers do not have the capability to perform packet 
accounting today.
So if accounting is really a requirement, then this service will not be widely
available from IP service providers anytime soon.

------------------------------------------------------------------------------

---------------------------------------

The first paragraph talks about "charge on a flat-rate basis".
The third paragraph talks about "flat-rate billing" and "charge based on..."

The point I made in my previous e-mail, which you didn't comment on, was that 
the second paragraph, in talking about packets, is outside the scope of the 
discussion on call accounting requirements.

If you would limit your comments to the subject at hand, which is accounting 
requirements to detect misuse of the priority service, and limit it to call 
setup requirements, not packet transfer requirements, maybe we could come to 
some quick agreements on the issues.

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 11 Oct 2002 15:16:52 -0400

On Friday, Oct 11, 2002, at 13:51 America/Montreal, [email-masked] 
wrote:
> If you would limit your comments to the subject at hand, which is 
> accounting requirements to detect misuse of the priority service, and 
> limit it to call setup requirements, not packet transfer requirements, 
> maybe we could come to some quick agreements on the issues.

Au Contraire.

The topic of all of my postings is generalised use of labels (per 
Carlberg's
general requirements draft).

On the topic of telephony requirements, which is different than the 
topic
that I've been talking about, I concur with Ken Carlberg.  There is a 
rough
consensus evident -- that rough consensus is different from your own 
espoused
view.  Like Ken, I don't plan to spend a lot more time responding to 
your
disingenuous postings.

Ran
[email-masked]

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep