RE: [Sipping] SPITSTOP: Requirements for Authorization Policies to tackle Spam for Internet Telephony and Unwanted Traffic

[<[e-mail]>]

Hi all,

A couple of comments and proposals for new requirements for discussion
as follows. 
(Note that I've provided some additional editorials directly to Hannes.)

Section 3.1: new requirements to be considered (for discussion): 

- Req-C x: Policies SHOULD allow usage of external user lists, e.g.
usage of address book or resource lists.
- Req-C x: Policies SHOULD allow an anonymous identity as a condition.
- Req-C x: Policies SHOULD allow the Subject header field value or a
part of the value to be used as a condition. 
- Additionally, it could be required that the user is able to define a
default rule (= action) which matches when no else rule is applied. (I
know that there are issues with this in the common-policy.) 
- "Sphere" was mentioned in the corresponding framework I-D, but I did
not find any requirements for it. I personally don't see it that
important, but could be anyway mentioned when included in the framework.
The requirements could be something like: "Req-C: Policies MAY allow to
make decisions based on the current state of the user. E.g. based on a
user selected active profile, or sphere or other presence information."

Comments to the existing requirements:
- Req-C 6: In addition to SIP method, also the content type and/or
offered (or used) media of the request SHOULD be allowed as condition. 
- Req-C 7: how about timezone in addition to date&time information?
- Req-C 9: Also authentication method could be a condition.


Section 3.2:

Req-A 6:  In addition to e-mail, SMS and MMS, also "other notifications"
could be supported.

In general, it'd be good to mention how the actions relate to each
other. E.g. if the redirection and notification can be both applied.
And, e.g., which actions exclude each other.

For example, "blocked", "politely blocked", "pending (=SPIT
text/consent)", "redirect" and "allowed" could be thought to exclude
each other. And "notification" and "mark" could be applied parallel to
those. On the other hand, redirect could also be seen as a parallel
operation.


Section 3.3: new requirement to be considered:
- Req-T 2: Policies MAY allow SIP message modifications, e.g. filtering
binary objects or contents of bodies of SIP messages.


Section 3.4:
Comments to the following requirements:
- Req-G 1: This could be explained more. E.g. what would be the real
"end user" requirement? Or, what additional value the hierarchy brings? 

- Req-G 4: does this cover discovering supported capabilities (e.g.
which extensions are supported and understood by a network element)?

Proposal for a new requirement: "Req-G X: The policies MUST allow
several Rule Makers for a policy."


BR, Eva Leppanen
 

>-----Original Message-----
>From: ext Hannes Tschofenig [mailto:[e-mail]] 
>Sent: 14 June, 2007 14:29
>To: SIPPING LIST
>Subject: [Sipping] Requirements for Authorization Policies to 
>tackle Spam for Internet Telephony and Unwanted Traffic
>
>Hi all,
>
>we have just submitted a new draft on "Requirements for Authorization 
>Policies to tackle Spam for Internet Telephony and Unwanted Traffic". 
>Please find the document here: http://fon.gs/spit-requirements
>
>This document replaces 
><draft-froment-sipping-spit-authz-policies-02.txt>.
>
>Ciao
>Hannes



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP