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

From: [email-masked]
Date: Wed, 18 Dec 2002 23:29:04 EST

In a message dated 12/17/2002 3:45:56 PM Eastern Standard Time, 
[email-masked] writes:

> [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

[KC] 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.

[MAP] I understand this problem with the word "priority", which I used in a 
general sense to include the 4 examples I provided in my presentation. That 
is also why my presentation includes the explicit statement that "priority 
here does not imply any particular mechanism, e.g., priority queuing" and why 
I did not use the word "priority" in the text I proposed for the "general" 
draft. The use of "priority" in the Pierce drafts is its normal English 
meaning, nothing more, the same as in the previously proposed "Resource 
Priority Header". It is not used in the sense of priority queuing, that is, 
transmitting one packet ahead of others.

> [MAP] capability that gives the user the ability to get a better service, at
> the possible disadvantage of others, requires auditing to detect
> misuse. This includes 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.

[KC] 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.

[MAP] I presume you meant IAA. I don't consider IAA to be a "priority 
service" in the context which I was talking about requirements. The IAA 
service as described does not contain any capability for one person to get 
better service over another. Besides, we have been concentrating on "call 
setup" characteristics, such as probability of setup, probability of 
disconnect, etc. These do not relate to IAA. If the intention is for the 
"general" draft to only talk about thing that are common to every "ETS" 
service, then the above argument would mean that "Authentication" should not 
be listed as a requirement, either.

If you mean something else by IAM, I'm sorry that I missed it.

[KC] 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?

[MAP] See comments above. The final sentence of the text that I proposed 
should include a notion of it applying to cases in which one user gets better 
service, such as "However, solutions used to realize ETS capabilities which 
provide one user with better service at the possible disadvantage of others 
should include the capability of an accounting mechanism to support auditing 
as defined in [RFC2975]." A similar qualification should be added to 
"Authentication".

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

[MAP] It can work fine in this regard if the Accounting requirement is in the 
appropriate one. Sorry that I was concentrating on the "general" draft. See 
below.

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?

[MAP] A statement about a requirement for Accounting in the Telephony draft 
could satisfy my perceived need, if that is in line with the structure of the 
two documents. It pertains to more than "MLPP". However, the current 
telephony draft only contains one paragraph about Accounting, and that is 
related to "Hybrid infrastructures that include and support connectivity to 
the PSTN". This sentence should be changed to not be restricted to the 
"interworking with the PSTN" case. The following is proposed:

   4) Application layer IP telephony capabilities MUST NOT preclude
     the ability to do accounting.

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

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 19 Dec 2002 14:27:02 +0000

> [MAP] I understand this problem with the word "priority", which I used
> in a general sense to include the 4 examples I provided in my
> presentation. That is also why my presentation includes the explicit
> statement that "priority here does not imply any particular mechanism,
> e.g., priority queuing" and why I did not use the word "priority" in the
> text I proposed for the "general" draft. The use of "priority" in the
> Pierce drafts is its normal English meaning, nothing more, the same as
> in the previously proposed "Resource Priority Header". It is not used in
> the sense of priority queuing, that is, transmitting one packet ahead of
> others.

thats fine.  I won't grill you about mechanisms :-)
it was just important to clarify the context and its association
of the term you brought up.

> [MAP] I presume you meant IAA. 

yes, my apologies, i meant IAA.

> I don't consider IAA to be a "priority
> service" in the context which I was talking about requirements. 

ok.

> The IAA
> service as described does not contain any capability for one person to
> get better service over another. 

i guess that depends on what you define as 'better'.  my understanding
is that they have been looking at using DSCP.  in addition, they have
put forth the reflexive DSCP draft.  how and the extent they wish to
deploy it is fodder for another thread.  i have not taken a closer
look at how the use application layer signaling.

> Besides, we have been concentrating on
> "call setup" characteristics, such as probability of setup, probability
> of disconnect, etc. These do not relate to IAA. If the intention is for
> the "general" draft to only talk about thing that are common to every
> "ETS" service, then the above argument would mean that "Authentication"
> should not be listed as a requirement, either.

in section 1.2 (the Problem statement) of the General requirements
draft, we specifically state:

  "A subsequent problem is to ensure that this support is not focused
   just on IP telephony applications. The I-Am-Alive (IAA) database
   system is an example of an emergency related application used in
   Japan that supports both signaled and non-signaled access by
   users[10]."

I feel this statement makes it clear that the draft is going beyond just
IP telephony.  I also totally disagree with the opinion that
Authentication should not be listed as a requirement.  If we stick with
the IAA example, then users that log on and stipulate ("I am alive")
must be authenticated so that the stored information has a measure of
validity.  And I certainly sympathize with the lack of interest in using
accounting to determine whether I am "abusing" the system by registering
that I am alive.

> [MAP] It can work fine in this regard if the Accounting requirement is
> in the appropriate one. Sorry that I was concentrating on the "general"
> draft. See below.

ok

> [MAP] A statement about a requirement for Accounting in the Telephony
> draft could satisfy my perceived need, if that is in line with the
> structure of the two documents. It pertains to more than
> "MLPP". However, the current telephony draft only contains one paragraph
> about Accounting, and that is related to "Hybrid infrastructures that
> include and support connectivity to the PSTN". This sentence should be
> changed to not be restricted to the "interworking with the PSTN"
> case. The following is proposed:
>

ok.  barring objections from other folks, I can change the 4'th 
requirement to what you propose above.

-ken

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 19 Dec 2002 12:53:19 -0500

On Wednesday, Dec 18, 2002, at 23:29 America/Montreal, [email-masked] 
wrote:
> such as "However, solutions used to realize ETS capabilities which

Aside:
	RFC-2975 is an Informational RFC.  It is NOT standards-track.  Anyone
can publish nearly anything as an Informational RFC (e.g. IP over 
carrier
pigeon is an Informational RFC).  All Internet Standards are RFCs, but
many many RFCs are NOT Internet Standards.

	So the existence of RFC-2975 is not by itself justification for an
IETF WG to include accounting in any standards-track document or 
informational
document.  The justification for including such needs to be made on its
own merits, not relying on mis-reference to a non-standards-track 
document
for justification.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 19 Dec 2002 12:56:29 -0500

On Wednesday, Dec 18, 2002, at 23:29 America/Montreal, [email-masked] 
wrote:
> draft

The text after "4)" is OK with me.

I'd be a bit happier if we said "application-layer accounting" rather 
than
"accounting", for the benefit of folks who read the document later and
haven't seen any presentations or list discussion where IP-layer 
accounting
was disclaimed.

Ran
[email-masked]