Subject: Re: [Ieprep] updated requirements documents (general)

From: [email-masked]
Date: Tue, 17 Dec 2002 14:20:29 EST

In a message dated 12/13/2002 8:13:24 AM Eastern Standard Time, 
[email-masked] writes:

[KC] As for your presentation in Atlanta, I have to apologize that while i
was present, I was engaged in another conversation.  It was my
impression that your presentation was specifically scoped at MLPP and
not ETS as a whole, which may explain in part why there were no
objections.  And finally, working group consensus is predominantly
reached on the list.  I didn't hear a call for humms when you spoke :-)

[MAP] No, my presentation was saying that the requirement for accounting 
(auditing) at the application layer (not the packet transport layer) is a 
common requirement for all "priority" services. That is, any capability that 
gives the user the ability to get a better service, at the possible 
disadvantage of others, requires auditing to detect misuse. This inlcludes 
ETS, MLPP, and a couple that are out-of-scope of IEPREP such as 911/112.

I believe the objections that have been raised in the past were mostly 
related to beliefs that I was advocating counting packets, a notion which I 
hope I dispelled once and for all in my presentation. Also, I believe it has 
been clearly stated that IEPREP listing something as a "requirement" does not 
in any way mandate that any specific vendor or carrier must provide it. Given 
this, I would like to hear objections to identifying "Accounting" as a 
requirement that must be included in any specification for providing 
"priority services", that is, objections to the specific text I've proposed 
below.

In a message dated 12/13/2002 8:26:03 AM Eastern Standard Time,  
[email-masked] writes:

> [MAP] 1) Accounting: Following my presentation in Atlanta at which no 
> objection was raised,

[RJA] Disagree.  There were several objections from operators during the 
meeting.  I was
in the room. 

[MAP] Kimberly's notes of the IEPREP meeting, distributed Nov 22, don't make 
any mention of any objection to what I was presenting and I didn't hear any. 
(The notes contain a reference to "Peter Lothberg chimed in on the 
unreasonableness of packet level accounting", in spite of the fact that I 
began my presentation with a clear statement that "I am not proposing packet 
level accounting.")

 [RJA] Moreover, the list discussion takes precedence over in-person meetings
under IETF process rules (unlike with some other standards groups).  And 
there are
numerous unresolved objections here on the list -- mainly because you haven't 
made
it clear what exactly you want to account for.

[MAP] See my first comment above.

[RJA] It would help further discussion a great deal if you could be more 
clear and very
specific in what objects you want.  Depending on what they are, folks here 
might
well agree with the specifics.

[MAP] In my presentation I listed some accounting objects that "are most 
common". I don't believe it is appropriate to discuss (or agree on) specific 
items at this point. I see that as a later function of SIPPING (if really 
part of SIP, which I presume it is) and is clearly application dependent. I 
certainly think that this list provides enough specificity to allow anyone to 
raise concrete objections to Accounting that are relevant to the issue at 
hand. I'm sorry, but I don't believe I have heard any objections which were 
addressing the subject at hand. There have been several about packet level 
accounting (which I never proposed) and some claim that no one would need to 
do accounting since "everyone" would charge flat-rate anyway (I'm not 
addressing the needs for billing), and I think also some claims that the 
network wouldn't care about misuse if has unlimited capacity (hardly worth 
commenting on).

To repeat that page of my presentation for those who missed it:

--------------------------------------------------------
What may be useful?

For each call setup or attempt, the following are most common:
- Calling and called party identification
- Time and duration of call attempt
- Priority level or special treatment requested and received
- Password or access code used *
- Disposition of call attempt

* It is recognized that security policies would normally require 
that the actual password or access code should not be stored in 
the accounting record, but there must be some way to determine, 
when examining the records, which code was (mis)used. For example, 
when a simple 4-digit pin is entered, which is sent through the 
audio path "in the clear" anyway, then storing the actual code 
received is not a further security problem.
---------------------------------------------------------

[MAP] To repeat my proposal:

> this should be moved to the Requirements section. I suggest the 
> following text, which I believe correctly reflects the need and avoids 
> any bad implications:
>
> 9) Accounting (auditing)
>
> Accounting represents a method of tracking actual usage of a service 
> for purposes of capacity and trend analysis, cost allocation, 
> auditing, and billing [RFC2975]. We assume that the usage of any 
> service better than best effort will be tracked and may subsequently 
> be billed to the user. Accounting for billing purposes is not 
> addressed as a general requirement for ETS. However, solutions used to 
> realize ETS should include the capability of an accounting mechanism 
> to support auditing as defined in [RFC2975].

[RJA] Disagree.  I'd be happy to add text saying that a solution "must not 
preclude
an operator from performing accounting", but not text making it a requirement.

[MAP] I never suggested any text saying that it is a requirement for an 
operator to perform accounting. The proposed text says "solutions ... should 
include the capability ... to support auditing." Anyway, the text in 2.1 of 
the draft pretty well dispells any idea that anything in this document places 
actual requirements on a service provider.

Mike Pierce
Artel

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 17 Dec 2002 20:45:20 +0000

> (auditing) at the application layer (not the packet transport layer) is
> a common requirement for all "priority" services. That is, any

to be precise, neither the General Requirements nor the Telephony
requirements document use the term '"priority" services'.  as you will
recall the term "priority" has caused a flurry of arguements on this
list, the previous list, and at meetings.  so if you are speaking
in terms of how the Pierce-draft(s) describe "priority", then the
above subject line you have used is incorrect and we are speaking 
past each other.

> capability that gives the user the ability to get a better service, at
> the possible disadvantage of others, requires auditing to detect
> misuse. This inlcludes ETS, MLPP, and a couple that are out-of-scope of
> IEPREP such as 911/112.
>
> related to beliefs that I was advocating counting packets, a notion
> which I hope I dispelled once and for all in my presentation. Also, I
> believe it has been clearly stated that IEPREP listing something as a
> "requirement" does not in any way mandate that any specific vendor or
> carrier must provide it. Given this, I would like to hear objections to
> identifying "Accounting" as a requirement that must be included in any
> specification for providing "priority services", that is, objections to
> the specific text I've proposed below.

One of Ran's objections stated that IAM doesn't not have a requirement
for accounting.  This in line with a conversation I had with one of
the IAM designers a while back.  This by itself means that there is a
type of application in which an accounting requirement is simply
out of scope.

the General requirements draft is meant to be minimal.  If there is a
need to go beyond it, one produces a draft that addresses a more 
specific case.  an example of this was done with the telephony
requiremenst draft.  in this case a statement about accounting was
placed in that draft's requirements section.

if you wish to continue this thread, please provide a response to the 
following:

1. address Ran's objection above.  by adding a requirement that
articulates a statement about accounting, how do you deal with an
application that has no concept about accounting?

2. provide a reason why the current structure of the two carlberg-ets-*
requirements (general followed by more specific) does not work.

3) why doesn't a statement about an accouting requirement in the
telephony requiremenst draft satisfy your perceived needs as they
relate to MLPP?  Is there another case that you are contemplating?
if so, what is it?

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