From 5e3976a29644227d1f062f36cf9448dac1c34796 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 5 Jun 2009 22:40:11 +0000 Subject: [PATCH] 0.2 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3227 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0268.xml | 35 +++++++++++++++++------------------ 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/xep-0268.xml b/xep-0268.xml index b9c5c4d0..6009fe17 100644 --- a/xep-0268.xml +++ b/xep-0268.xml @@ -46,6 +46,12 @@ mwild1@gmail.com mwild1@jaim.at + + 0.2 + 2009-06-05 + mw/psa +

Added more detailed information about the solution element; removed the suggestion element since the solution element can be used by both reporting entities and receiving entities; added notes about processing of incident reports by receiving entities.

 + 0.1 2009-04-30 @@ -101,9 +107,6 @@ 2 - - 192.0.2.1 - abuser@abuse.lit loser@abuse.lit @@ -161,7 +164,7 @@ -

If the reporting entity determines a solution to the problem, it MAY send out a revised incident report containing a <solution/> element.

+

If the reporting entity determines a solution to the problem or a receiving entity has a suggested solution to the problem, it SHOULD send out a revised incident report containing a <solution/> element (or the reporting entity can include a solution in its initial report). The solution element can include any of the elements defined for the <description/> element, such as the <ip/> element (since the XMPP server of a source JID might know the IP address of the connected entity).

- banned the offenders + + + 192.0.2.1 + + + iptables -A INPUT -s 192.0.2.1 -j DROP @@ -178,19 +186,10 @@

Further definition of the <solution/> element will be provided in a future version of this specification.

 - -

If an entity that receives an incident report has a suggested solution to the problem, it MAY send an incident message containing a <suggestion/> element.

- - - - here is how we solved the problem... - - - - ]]> -

Further definition of the <suggestion/> element will be provided in a future version of this specification.

+ +

Unless explicitly configured to do so, a receiving server SHOULD NOT automatically modify its configuration based on receipt of an incident report, even from a trusted server, but instead SHOULD prompt the human administrator(s) so that they can take appropriate action.

+

A receiving server MAY accept incident reports from peers that are not on its "trust list", but SHOULD treat such reports with caution and provide them to the human administrator(s) of the server.

+

A receiving server MAY forward reports that it receives to other servers it trusts