Re: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ?

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Fri, 09 May 2008 11:08 UTC

Return-Path: <rucus-bounces@ietf.org>
X-Original-To: rucus-archive@ietf.org
Delivered-To: ietfarch-rucus-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A140D3A6822; Fri, 9 May 2008 04:08:44 -0700 (PDT)
X-Original-To: rucus@core3.amsl.com
Delivered-To: rucus@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA2A3A6822 for <rucus@core3.amsl.com>; Fri, 9 May 2008 04:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level:
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I6d8kgNdfh9 for <rucus@core3.amsl.com>; Fri, 9 May 2008 04:08:40 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 082AC3A681E for <rucus@ietf.org>; Fri, 9 May 2008 04:08:39 -0700 (PDT)
Received: (qmail invoked by alias); 09 May 2008 09:18:20 -0000
Received: from dhcp-25-105.ripemtg.ripe.net (EHLO [193.0.25.105]) [193.0.25.105] by mail.gmx.net (mp021) with SMTP; 09 May 2008 11:18:20 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+9hs4Ha+G9Ur9umVRc21NtlQdvJl49fNnEkFXOM+ fyVdrP03xNxpi0
Message-ID: <482416C8.8010407@gmx.net>
Date: Fri, 09 May 2008 12:18:00 +0300
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Saverio Niccolini <Saverio.Niccolini@nw.neclab.eu>
References: <C1FCAF37-F378-4961-99C5-B5DA024E7F9B@voxeo.com> <481C953A.5000704@gmx.net> <45EDF1C5D301ED41A339796A9F979F720FDA64@eris.office> <482408B5.4050802@gmx.net> <45EDF1C5D301ED41A339796A9F979F720FDFC9@eris.office>
In-Reply-To: <45EDF1C5D301ED41A339796A9F979F720FDFC9@eris.office>
X-Y-GMX-Trusted: 0
Cc: rucus BoF <rucus@ietf.org>
Subject: Re: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ?
X-BeenThere: rucus@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" <rucus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rucus>, <mailto:rucus-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/rucus>
List-Post: <mailto:rucus@ietf.org>
List-Help: <mailto:rucus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rucus>, <mailto:rucus-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rucus-bounces@ietf.org
Errors-To: rucus-bounces@ietf.org

Hi Saverio,

to have 2 documents as output of the WG sounds good for me. One that 
focuses on the framework & scenarios and another one that points to the 
class of mechanisms (considering the other document).

Good proposal!

Ciao
Hannes


Saverio Niccolini wrote:
> Hannes,
>
> I am fine with keeping scenarios as Dan described to give people
> an idea of what they risk (kind of pitfalls) if they not look carefully
> into configuration of certain polcies.
>
> Actually this is part of what we think would be the direction of RUCUS:
> -- "reference scenario": 
> let's take a reference scenario, e.g. a simple standard SIP one like
> slide 11 of Henning's presentation
> (https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) 
> and let's add what the pitfalls are (Dan's doc), add the considerations
> of David about the problem statement and the ones of Otmar which
> people seems to agree on
>
> -- "framework" or "communication glue" --> see Jan's email
> for this we see slide 11 of Henning's presentation (https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm)
> as the best example --> it includes polcies and signalling extensions to
> query oracles and allow distirbuted decisions --> it would not hint to 
> specific solution mechanisms if well defined
>
> -- "class of mechanisms" -- see also Jan's email
> this is what Jonathan proposed at the BOF and people agreed on,
> actually we speak about classes since single mechanisms do not make
> entire sense at this point in time
>
> I do not seen any problem with this approach and I hope to see large
> consensus, I think this is clean and simple and we can achieve this in
> the 6 months of an EG.
>
> Can we agree on this, write the charter proposal around that, have
> ADs convinced and start real work?
>
> Comments?
>
> Saverio
>
> ============================================================
> Dr. Saverio Niccolini
> NEC Laboratories Europe, Network Research Division	
> Kurfuerstenanlage 36, D-69115 Heidelberg
> Tel.     +49 (0)6221 4342-118
> Fax:     +49 (0)6221 4342-155
> e-mail:  saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!!
> ============================================================
> NEC Europe Limited Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL Registered in England 2832014
>  
>   
>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
>> Sent: Friday, May 09, 2008 10:18 AM
>> To: Saverio Niccolini
>> Cc: Dan York; rucus BoF
>> Subject: Re: [Rucus] Any further comments on 
>> draft-york-sipping-spit-similarity-scenarios-00.txt ?
>>
>> I agree with you, Saverio. Nevertheless it is a good idea to 
>> keep the scenarios Dan has described in his document in mind 
>> and to consider them in the overall solution.
>>
>>
>> Saverio Niccolini wrote:
>>     
>>> Dear Hannes,
>>>
>>>   
>>>       
>>>> I like your document, as mentioned previously already. I 
>>>>         
>> shows some 
>>     
>>>> of the limitations with systems that use learning of past 
>>>>         
>> behavior as 
>>     
>>>> their basis for future actions. Some of the statistical techniques 
>>>> belong to this category.
>>>>     
>>>>         
>>> we all agree statistical techniques do have limitations, 
>>>       
>> but they are 
>>     
>>> also powerful and this does not mean they should not be 
>>>       
>> considered in 
>>     
>>> the RUCUS work
>>>
>>> I remember all the list of methods indicated by Henning 
>>>       
>> during the BOF 
>>     
>>> as most promising (check his ppt slides):
>>> -- identity-based
>>> -- statistics
>>> -- price-based
>>>
>>> For some of the scenarios Dan describes in his draft the 
>>>       
>> statistical 
>>     
>>> techniques will never come into play:
>>> -- "emergency notifications": if you have strong identities 
>>>       
>> in place 
>>     
>>> and you are sure nobody can steal them, you just need to insert the 
>>> URIs that are allowed to send "emergency notification" into 
>>>       
>> the white 
>>     
>>> list --> no need to apply statistics, just work on policy and 
>>> identity-based mechanisms (statistics are useful here to check 
>>> misbehaviours)
>>>
>>> -- Urgent Notification Systems: a bit more complicated but there is 
>>> always a previous relationship between caller and callee, thus also 
>>> here one could get around them without statistics but with policies 
>>> and identity-based mechanisms
>>>
>>> -- for the other systems I would always repeat what I just wrote:
>>> apply policies and identity-based mechanisms
>>>
>>> The statistics are good when ther eis no previous 
>>>       
>> relationship between 
>>     
>>> the caller and the callee and this is why they are useful
>>>
>>> Thus if you want to choose the three class of mechanisms that RUCUS 
>>> should suggest just choose these three..
>>>
>>> Cheers,
>>> Saverio
>>>
>>>   
>>>       
>>>> However, the most important question is: What should 
>>>>         
>> happen with the 
>>     
>>>> document at the end?
>>>> Furthermore, the document points to potential problems to 
>>>>         
>> a specific 
>>     
>>>> category of solutions. For systems that do not rely on learning 
>>>> techniques these scenarios are not a problem as such.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>
>>>> Dan York wrote:
>>>>     
>>>>         
>>>>> SIPPING & RUCUS,
>>>>>
>>>>> Because I've had some various pieces of feedback on the
>>>>>       
>>>>>           
>>>> document, I'm
>>>>     
>>>>         
>>>>> going to rev draft-york-sipping-spit-similarity-scenarios
>>>>>       
>>>>>           
>>>> in the next
>>>>     
>>>>         
>>>>> week or so to incorporate that feedback.  Since I'm doing so, I 
>>>>> thought I'd just ask.... anyone else have comments on:
>>>>>
>>>>>    
>>>>>
>>>>>       
>>>>>           
>> http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios
>>     
>>>> -
>>>>     
>>>>         
>>>>> 00.txt
>>>>>
>>>>> Additional scenarios you think I should include.... points of 
>>>>> clarification... whatever?
>>>>>
>>>>> Thanks,
>>>>> Dan
>>>>>   
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> Rucus mailing list
>>>> Rucus@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rucus
>>>>
>>>>     
>>>>         
>>> ============================================================
>>> Dr. Saverio Niccolini
>>> NEC Laboratories Europe, Network Research Division	
>>> Kurfuerstenanlage 36, D-69115 Heidelberg
>>> Tel.     +49 (0)6221 4342-118
>>> Fax:     +49 (0)6221 4342-155
>>> e-mail:  saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!!
>>> ============================================================
>>> NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
>>> London W3 6BL Registered in England 2832014
>>>  
>>>   
>>>       
>>     

_______________________________________________
Rucus mailing list
Rucus@ietf.org
https://www.ietf.org/mailman/listinfo/rucus