ATOCA, 82nd IETF

Contents

Agenda

Milestone Review

Requirements

Lightweight Delivery

Date: Friday, November 18, 2011
Location: Taipei, Taiwan
Chairs: Martin Thompson, Scott Bradner
Substitute Chair: Adam Roach
Notetaker: Ted Hardie
Audio Archive: http://www.ietf.org/audio/ietf82/ietf82-102-20111118-1111-am.mp3

Agenda

Presenter: Chair
Slides: http://www.ietf.org/proceedings/82/slides/atoca-0.pdf

Hannes Tschofenig requested moving the requirements document discussion before the "Lightweight Delivery" discussion. No objections raised. Agenda decided to proceed as follows:

1. Milestone Review

2. Hannes: Requirements: Open issues, architecture, and scope

3. Richard Barnes: Lightweight Delivery

4. Gabor: EAS in 802.11 draft-bajko-atoca (time permitting)

Milestone Review

Presenters: Richard Barnes, Chair
Slides: http://www.ietf.org/proceedings/82/slides/atoca-1.pdf

The meeting began with a short review of the interim meeting. Basic message: removed distribution protocol in favor of a registration mechanism and a broadcast protocol. The registration protocol is needed for alert targeting. This implies the need for senders to advertise publication points and recipients to register information about themselves (location, language, capabilities, contact uris). Delivery could be by the contact URIs (smpt, xmpp). May have a scaling problem; tcp may be too heavyweight.

Once an alert is received, how is it verified? Hash pre-image and signature over the alert body were suggested. Robert discussed the proposed new milestones. The second milestone ("addressing security") was important during IESG/IAB review. He proposes that it be edited, not dropped. Richard believes that it is an attribute of the framework draft; Hannes notes that the first doc talks about security a good bit, but misses out on discussion of performance and congestion issues. They could be there, but lacking consensus on those, they have not gone in. Robert notes that order of presentation is important; if the framework comes in before the mechanism documents, that is fine. The room believes that these should be added to the framework document, rather than security into a separate document; the milestone wills tay, but one document will satisfy both the first and second milestones.

Dan asks where discussion of current technologies which might meet these would be? Answer was that these would be discussed in the mechanism documents. Robert notes that the different aspects (security, performance, congestion) should be non-empty when sent for publication, so he doesn't have to recycle them. Richard asks that the minutes note he supports these milestones and timing. Randy Gellens asks if that document defines scope? Brian Rosen says yes, that is where it scopes the problem. Hannes notes that it is in there, but it could be a separate section. Hadriel aren't these use cases? Hannes says no, that it is for the properties. Richard says that the use cases can be simply enough described it goes in the framework doc. Hadriel says that it is use cases, not scopes.

Hannes asks Randy for a review of the current document. Randy agrees to review the document.

Adam asks that anyone with current use cases to send them to the list.

Omitted from the previous list: mime type for CAP, SIP Event Package. Discussion short-circuited by Robert noting that he will AD sponsor the mime type, and he will ensure ecrit and atoca review it. SIP event package discussion deferred until more discussion of mechanisms.

Requirements

Presenter: Hannes Tschofenig
Slides: http://www.ietf.org/proceedings/82/slides/atoca-3.pdf

Llamas! (See slides for details)

Brian Rosen asks whether the architecture document should replace specific mechanisms (e.g. remove LoST and say "Discovery"). Hannes said yes that is the intent.

Brian Rosen: we haven't captured the notion that you don't get every notification from a single server. We do need opt-in options for some use cases (enterprises). From an architecture perspective, though, the critical thing to include is that we don't wed ourselves to the one-to-one view.

Hadriel: when we talk about multicast, are we talking about application layer or IP layer or ethernet layer?

Hannes and Richard discuss this; in some cases we are talking about physical broadcast. Brian notes that there are networks in which multicast is being enabled for limited uses and this might be one. Clarifying that we are talking about using both unicast and multicast.

Robert clarifies that we are talking about mulitple authorities, both split according to topic and potentially to multiple authorities for a single topic. Generally agreement that we will support multiplicity.

Jonathan Lennox notes that having more than one access network send you send the alert to the same individual; Brian notes that there will be a way to deal with this, because it also happens with un-acknowledged broadcasts being re-broadcast.

Of course layer at which this occurs will impact traversal, transport, and other Ts.

Lightweight Delivery

Presenter: Richard Barnes
Slides: http://www.ietf.org/proceedings/82/slides/atoca-2.pdf

Richard, Matt, and Karen show their draft slides, but as an advertisement and request for review, since we are out of time.