Re: [Rucus] Charter proposal

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

Dear Cullen,

if you look carefully in the charter text (without always thinking
that we want to push only spam score) you will see that this charter
proposal is nothing more than:
-- a mix of Henning's presentation on architectural issues
merged with the 3 mechanisms proposal of Jonathan

I do not see any hidden thing nor pushing of something that has
no consensus.

We all agree that work currently established in SIPPING should have
precedence and policy framework is (one of) the best candidates 
--> maybe this needs to be added as Mary pointed out

I personally see no problems with the charter, if you still see
them can you please detail them more?
If we do not know what is your exact objection, we will have hard
time to meet requirements for forming the EG...

Looking forward to your answer,
Saverio

============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
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: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Juergen Quittek
> Sent: Wednesday, June 25, 2008 9:10 AM
> To: Cullen Jennings; [e-mail]
> Cc: Jan Seedorf
> Subject: Re: [Rucus] Charter proposal
> 
> Hi Cullen,
> 
> Thanks for the feedback!
> 
> On 24.06.08 21:40  "Cullen Jennings" <[e-mail]> wrote:
> 
> > My recollection of the BOF (without going and checking the 
> notes so it
> > may be wrong) is that there was reasonable consensus on a 
> specific set
> > of work items in an EG that involved the following:
> > 
> >      Taking some small set (~3) of techniques from existing drafts,
> 
> Maybe we have to be more clear about what a "technique" is.
> I think the charter proposal covers techniques from several existing
> drafts including
>   a) configuring and communicating authorization policies
>   b) querying oracles (trust brokers)
>   c) conveying downstream metrics to use trust among peers
> By chance or intention these explicitly mentioned items are 
> exactly three.
> 
> >      remove the implementation details and focus on the 
> basic approach,
> >      turn them into a few pages and discuss the pros and cons and
> >      applicability assumptions. From this form a plausible 
> picture of
> >      one way that might help mitigate unwanted communications.
> > 
> > This charter seems to be for a rather more specific set of 
> work items,
> > namely mechanisms for exchange of spit-related information between
> > various parts of the SIP infrastructure.
> 
> I do not see in what respect the charter proposal is specific.
> I would understand if you told us it would be too general, because
> it includes all work that has been contributed in drafts so far.
> 
> An essential property of all three items a)-c) is that they require
> communication between entities of the SIP infrastructure,
> be it for exchanging very general authorization policies or for
> exchanging very specific information on a single call.
> I consider it quite natural, that the charter proposal reflects this.
>    
> 
> >                                           It's quite possible that
> > that's an important part of the solution space, but I 
> didn't hear any
> > consensus in the room that people wanted to focus solely on that.
> 
> Again, I do not see any part of the solution space that is excluded.
> Can you give an example of a part of the solution space that is
> actually excluded. This would be extremely helpful.
> 
> Thank you,
> 
>     Juergen
> 
> 
> > I'd love to see an EG formed around SPAM, but I do think that that
> > group needs to be chartered more along the lines of the consensus
> > reached in Philadelphia. I'd encourage you to go back and revise the
> > draft charter so it's more consistent with that.
> > 
> > Cullen <with my AD hat on>
> > 
> > 
> > On Jun 10, 2008, at 5:54 AM, Jan Seedorf wrote:
> > 
> >> Dear all,
> >> 
> >> A short while ago I sent an e-mail on this list, proposing a
> >> direction and scope for RUCUS to work on as an EG. I received some
> >> feedback on this list and some off-list. Since I did not 
> receive any
> >> negative comments (convincing me that this is the wrong direction),
> >> I tried to write these ideas up in a charter proposal for RUCUS.
> >> Below you can find a suggestion for a charter, describing what I
> >> think should be the scope of RUCUSEG, the work to be done, and the
> >> corresponding achievable goals within the scope of an EG.
> >> 
> >> Obviously, this is open for discussion. Any input/comment 
> on this is
> >> appreciated.
> >> 
> >> Btw: We plan to organise a one-day workshop in Heidelberg (right
> >> after IPTComm 2008) in order to discuss potential IETF work in the
> >> area of Unsolicited Communications and to make progress on 
> a charter
> >> for RUCUSEG agreed on by the community. I believe Saverio is going
> >> to post details regarding this workshop on this list soon.
> >> 
> >> Kind regards,
> >> Jan
> >> 
> >> Charter Proposal for RUCUS:
> >> ---------------------------------------
> >> With massive deployment of SIP infrastructures it is foreseeable
> >> that an increased amount of unsolicited communication will impose a
> >> potentially severe threat for real-time applications. 
> Efforts on how
> >> to reduce such a threat have received a lot of attention 
> in the IETF
> >> and have been recognized as an important item to be investigated by
> >> SIPPING. Preliminary
> >> investigations resulted already in the publication of RFC 5039.
> >> 
> >> Unfortunately, so far, further discussions on the issue 
> did not find
> >> a big consensus on the approach to be followed. On the other hand
> >> first products and solutions are now being developed and there is a
> >> big interest from different institutions to allow interoperability.
> >> This interest is reflected by many individual draft submissions,
> >> indicating an active community working in the area.
> >> 
> >> For effectively mitigating unsolicited communications, an exchange
> >> of information between different entities of a SIP infrastructure
> >> ("communication glue") is required. Which information is relevant,
> >> where in the network it is generated, and with which entities it
> >> needs to be exchanged depends on the organization of the 
> network and
> >> of communication between users (e.g., closed, semi-open, or open
> >> groups). Examples of such "communication glue" are: configuring and
> >> communicating authorization policies, querying oracles (trust
> >> brokers), or conveying downstream metrics to use trust among peers.
> >> Such communication would allow for automated decisions with respect
> >> to unsolicited communication, so that proper actions on a SIP
> >> message can be taken (e.g., "forward to mailbox"). As a 
> result, such
> >> "communication glue" would enable distributed communication and
> >> allow mechanisms from different vendors to work together while
> >> mechanisms for mitigation can evolve and follow the threat evolutio
> >> n.
> >> 
> >> It is not clear yet what precise properties are necessary to enable
> >> the exchange of information collected at different locations in a
> >> network (by different entities). A key challenge which has been
> >> identified for standardizing such communication is that attacks and
> >> mitigation mechanisms are likely to evolve. This implies that a
> >> rather generic and flexible standard for information exchange is
> >> required, because a fixed standards tied to known potential attacks
> >> only may soon be outdated.
> >> 
> >> Thus, in the spirit of an Exploratory Group, RUCUSEG will explore
> >> the problem space and confine requirements for such flexible
> >> exchange of information among different entities of a SIP
> >> infrastructure. To lay out the path for a potential WG,
> >> RUCUSEG will derive the properties for mechanisms to communicate in
> >> a distributed setting, separating concrete mechanisms from
> >> communication protocols. As a main result, RUCUSEG will identify
> >> what communication protocol properties are necessary to achieve
> >> flexible exchange of information in a way that it is independent of
> >> concrete mechanisms and allows for evolving
> >> mechanisms.
> >> 
> >> In order to keep the work achievable within the context of an EG,
> >> RUCUSEG will select a few (e.g., 3) prototypical classes of
> >> mechanisms as key ones and then work on confining how these could
> >> fit in an overall architecture and what kind
> >> of communication between entities would be necessary for these
> >> classes of mechanisms in a distributed setting. The main
> >> goal of RUCUSEG is to summarize these considerations in a document
> >> and to derive achievable goals for a potential WG which can then
> >> start work in order to standardize communication for reducing
> >> unsolicited communications.
> >> 
> >> -- Goals/Milestones (6-12 months after work starts)
> >>  -- WG charter for a follow-up WG (with consensus on the 
> mailing list)
> >>  -- document on recommendations and achievable goals for a WG
> >> 
> >> ============================================================
> >> Jan Seedorf
> >> Research Scientist
> >> NEC Europe Ltd., NEC Laboratories Europe, Network Division 
> >> 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
> >> _______________________________________________
> >> Rucus mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rucus
> > 
> > _______________________________________________
> > Rucus mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rucus
> 
> _______________________________________________
> Rucus mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rucus
> 
_______________________________________________
Rucus mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rucus