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

["Saverio Niccolini" <[e-mail]>]

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.     [phone]
Fax:     [phone]
e-mail:  [e-mail] <-- !!! 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:[e-mail]] 
> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rucus
> >>
> >>     
> >
> >
> > ============================================================
> > Dr. Saverio Niccolini
> > NEC Laboratories Europe, Network Research Division	
> > Kurfuerstenanlage 36, D-69115 Heidelberg
> > Tel.     [phone]
> > Fax:     [phone]
> > e-mail:  [e-mail] <-- !!! NEW ADDRESS !!!
> > ============================================================
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014
> >  
> >   
> 
> 
_______________________________________________
Rucus mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rucus