Re: [Sipping] Pushing Policies towards the Sender's Domain

[Hannes Tschofenig <[e-mail]>]

Hi Saverio,

Saverio Niccolini wrote:
> Hi Hannes,
>
> to add on what Juergen said, what we adressed in our SPITSTOP
> draft was not meant to cover only the authorization policies
> as you are saying, the authorization policies are just a special case
> of the possible communications between domains, others are;
> -- info related to SPIT estimations
>   

Have you looked at the following document 
http://www.tschofenig.priv.at/drafts/draft-schwartz-sipping-spit-saml-00.txt
Is this close to the mechanisms you have in mind?
(ignore the encoding in a SAML assertion for a moment)
> -- messages explaining to the sender domain why the message was blocked
>   
If you are talking about ordinary SIP mechanisms then that is fine for 
me. This might help the sender
Is this your intention or to share blacklists between the two domains?
> I clearly see these two points having priority over the authorization
> polices when it comes to pushing info towards the sender domain.
>   
In some sense this is quite similar to "authorization" policies. The 
difference is, however, whether you do the interaction based on 
individual calls or on an aggregate

Ciao
Hannes

> Cheers,
> Saverio
>
> ============================================================
> Dr. Saverio Niccolini
> Senior Research Staff Member
> Network Laboratories, NEC Europe Ltd.
> Kurfuerstenanlage 36, D-69115 Heidelberg
> Tel.     [phone]
> Fax:     [phone]
> e-mail:  [e-mail]
> ============================================================
> NEC Europe Limited Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL Registered in England 2832014
>  
>   
>
>   
>> -----Original Message-----
>> From: Juergen Quittek [mailto:[e-mail]] 
>> Sent: Sunday, June 17, 2007 2:30 PM
>> To: Hannes Tschofenig; SIPPING LIST
>> Subject: Re: [Sipping] Pushing Policies towards the Sender's Domain
>>
>> Hi Hannes,
>>
>> I fully agree, that pushing policies between domains should 
>> get low priority at this point in time in the context of 
>> standards required for SPIT prevention.  This is why we did 
>> not cover it in draft-niccolini-sipping-spitstop and just 
>> made the note that you cited below pointing to 
>> draft-froment-sipping-spit-authz-policies
>> where it seemed that this was included.
>>
>> It is good that you replaced 
>> draft-froment-sipping-spit-authz-policies with 
>> draft-froment-sipping-spit-requirements that only focuses on 
>> requirements.
>>
>> Thanks,
>>
>>     Juergen
>>
>>
>> --On 16.06.07 16:03 +0200 Hannes Tschofenig wrote:
>>
>>     
>>> Hi all,
>>>
>>> when reading through the documents I came across the following 
>>> statement in <draft-niccolini-sipping-spitstop-00.txt>:
>>>
>>> "
>>>    Please note that the described reference scenario does 
>>>       
>> not addresses
>>     
>>>    management interfaces to entities involved in SPIT prevention.  A
>>>    first approach to this issue has been made is described in
>>>    [I-D.froment-sipping-spit-authz-policies].
>>> "
>>>
>>> it seems that some parts of
>>> <draft-froment-sipping-spit-authz-policies-02.txt> got 
>>>       
>> misunderstood.
>>     
>>> There are some text paragraphs in
>>> <draft-froment-sipping-spit-authz-policies-02.txt> that envisioned 
>>> that the authorization policies are distributed to other 
>>>       
>> domains, and 
>>     
>>> in particular towards the sender's domain. There is obviously the 
>>> question what you would but in these policy documents, when to 
>>> distribute them and whether there are potential privacy 
>>>       
>> problems with that approach.
>>     
>>> This is an interesting technical issue BUT I would put it on my 
>>> priority list for work that has to be done in the SPIT prevention 
>>> space to the end of the queue. This lead us actually to 
>>>       
>> create a new 
>>     
>>> document (see
>>> http://fon.gs/spit-requirements)  that focuses purely on 
>>>       
>> requirements 
>>     
>>> for authorization policies that are not distributed between domains.
>>>
>>> I wonder what other people think about pushing policies towards the 
>>> sender's domain.
>>>
>>> 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
>>>       
>>
>> -- 
>> Juergen Quittek        [e-mail]       Tel: +49 
>> 6221 4342-115
>> NEC Europe Limited,    Network Laboratories        Fax: +49 
>> 6221 4342-155
>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   
>> http://www.netlab.nec.de
>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL, 
>> UK Registered in England 2832014
>>
>>
>> _______________________________________________
>> 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
>>
>>     



_______________________________________________
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