Re: [Rucus] Charter proposal

[Cullen Jennings <[e-mail]>]

On Jun 25, 2008, at 9:21 AM, Saverio Niccolini wrote:

> 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:

I was simply trying to help this charter move forward - I basically  
regret having sent any email on it now.

>
> -- 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.

I did not mean to imply it was.

>
>
> 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

_______________________________________________
Rucus mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rucus