Subject: [Atoca] Summary of "Language and Media Type" Discussion
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Date: Sun, 27 Feb 2011 12:22:13 +0200
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <earlywarning.ietf.org>

Hi all, 

in the discussion around the language and media type your feedback focused on the language part; the media type aspect wasn't really touched. 

In any case, I again think we need to differentiate two aspects here: 

1) Policy

For certain types of alerts governments may decide in what languages are supported in alerts. In other cases the alert message author may make that decision. 

2) Technology 

It would be important to have some mechanism to actually allow the potential recipient to indicate what languages he or she prefers. Martin suggested a Accept-Language header concept and Richard refined it. 

The language tag in the CAP encoded alert, as raised by Art, would then indicate in what language the specific alert is using.

To address this issue in the document two modifications are needed: 
a) In http://tools.ietf.org/html/draft-ietf-atoca-requirements-01 I believe it is useful to clarify that we are talking about (2) and that (1) may decide what is being used. 
b) In http://tools.ietf.org/html/draft-rosen-atoca-cap-01 the text Richard and Martin proposed would be added. 

Ciao
Hannes

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 27 Feb 2011 12:11:07 +0200
To: [email-masked]
Subject: [Atoca] Summary of "Requirement D2: Large Audience" Discussion

Hi all, 

thank you for your feedback on the long thread regarding the large audience requirement. 

Your feedback went in various directions, some of them were not related to the initial question. 

The initial question was about the refinement of the currently provided text that does not further specify a **number** for large audience. 

Two suggestions were made to deal with this issue: 

1) Talk about broadcast

2) Segment the numbers into groups depending on the likely number of recipients. 

Both approaches sound fine to me but I believe the former might be more appropriate because it points to the different architectural variants currently described in the document. 

I believe that this would be a good discussion topic for the upcoming IETF meeting. In particular, it would be interesting to discuss what tools we have in SIP to deal with the fulfillment of some of these requirements.  

The discussion then went on and lot of focus was spent on the "acknowledgment" messages that a receiver may sent as a confirmation of an alert delivery. 
There, a number of issues were raised, such as 
* At what layer does the ack happen? (e.g., SIP 200 OK, transport layer, application layer ack)
* Is the ack useful for cases were the alert message it targeted to a specific set of receivers rather than broadcasted? 
* Are we bound to the capabilities of the underlying communication infrastructure? 
* What are the scalability constraints? 
* Is an aggregation mechanism for acks useful? 

Ciao
Hannes

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 27 Feb 2011 11:20:54 +0200
To: [email-masked]
Subject: [Atoca] Summary of "Requirement for Originator Authentication?" Discussion

Hi all, 

thank you for your feedback on the topic of originator authentication. 

From the responses I see three aspects emerging: 

1) Deployment choice vs. technological capability 

How authorization policies would look like and what specific information is used to determine who is authorized and who isn't is a deployment decision. 

However, there needs to be technology available to actually provide this information. Identity-based authorization was mentioned (as a low hanging fruit) and the technical solution is to offer identity information about the entity that distributes the alert message. 

Other more sophisticated approaches (from a technology point of view) are trait-based authorization mechanisms. 

Your feedback raised the question whether we can re-use these security mechanisms from the underlying communication infrastructure? E.g. for example from SIP and XMPP? 

2)  Hop-by-hop vs. end-to-end authentication 

I got the impression that we need to allow both building blocks to be used rather than to focus on either one of them. 

Btw, CAP payloads are not end-to-end protected with S/MIME but rather with XML DSig. Not that either one of them is simpler but what would be appropriate to use in our context?

3) Identity scheme

If we have an identity based authorization then there is obviously the question about the types of identities one needs to deal with. CAP is very relaxed on this issue and does not provide a lot of constraints. So, I suspect the constraints to rather come from the underlying communication infrastructure. 

In the area of SIP we had lots of discussions around SIP Identity and a discussion of the different identities can be found in http://tools.ietf.org/html/rfc5025#section-3.1.1 (based on the discussions around Common Policy).

Is it too far fetched to assume that the underlying communication infrastructure provides the identities for us?

Ciao
Hannes