Minutes for ATOCA at IETF-interim-2011-atoca-1
minutes-interim-2011-atoca-1-00

ATOCA Interim Virtual Meeting - 2011-09-13T20:00:00Z
====================================================

Slide 2: How Alerts work Today -- overview
------------------------------------------
two-step model:
- authorities distribute alert to subscribers (networks) - one protocol
- networks broadcast alert to recipients without 

Brian Rosen: Current systems do this, but not sure we want to make the jump they
ought to do it this way.
RLB: this is a question to answer is if two systems with different protocols is the
right approach
Keith Drage: Some things are not going to change (e.g. mobile phones)

Slide 3: how alerts work today -- distribution
----------------------------------------------
small, static list
some prior art

Slide 4: How alerts work today -- broadcast
-------------------------------------------
large, very dynamic list
depends on what device is connected to/listening on
some prior art

Slide 5: How alerts work tomorrow?
----------------------------------
One approach: extend existing architecture/frameworks to IP
* nice to bridge alerts in addition to packets (e.g. cell to wifi)

Slide 6: Standards Requirements
-------------------------------
If we expect some arbitrary IP device to receive alerts, then we need to define a
standard for 
BR: Showing two-level of distribution is way too simplistic; there's really many
levels of distribution. The cell phone example is one example of three-level.
Dave Crocker: One of the things in these types of discussions is if these models are
adequate
BR:  I agree with that, and that's why I think there's no technical need that
distinguishes the distro side from the broadcast side
RBL: In the distro model, you have a fixed layer that needs/wants robustness, while
the broadcast model doesn't need or support that
BR: I think the fundamentals are identical
RBL: I think these things look more alike than they are different
DR: What different mechanisms do you see for systems in place, mine is email.  My
model is MUA to MTA which is incredibly simplistic, but still useful for discussion.
While there are some others that have more elaborate models built on the first to
cover specific discussions.
Mark Wood: One of the things we found in researching using mobile networks.  You need
to stop look at point-to-point protocols and start looking at point-to-multipoint in
order to scale.  If a network wishes to particpate, while their network is small, the
recipient number is very large, and geolocation a factor.
BR:  I think the distribution model is not 1:1, but that there are some number of
intermiediaries.
MW:  I think there are things to be concerned about within and across the layers.  We
need to make sure we carry enough information for next stage to continue (e.g. the
alert polygon)
BR:  I agree that we have these things to worry about.  I think the geolocation
filtering needs to be applied at various levels.
MW:  I think this implication is useful for moving forward, but we need to make sure
geoloc information is transmitted
KD:  Until we define the intermediary, we don't know what information we need to
include.  Second, the author appeared to be jumping directly from the fact that it
was an IP based protocol, to the assertion that IETF needed to define a standard for
it. If there is just a need to render text, there may not be a need for a new
standard. I wish to see the identification of an interoperability need before we
progress to defining a standards track document.
DC:  Even if you are using text, you need to do profiling, and there are 3 or 4
different ways to profile
RLB: In either case, we need an RFC to define these things.
James Polk: There's another aspect you're glossing over; you're only focusing on
national alerts.  Not everywhere that FiOS is will get the same alert.   Sometimes
only a very small slice of FiOS will get it.

Slide 7: Proposed Milestones
----------------------------
* architecture document
* secure alert format (e.g. signatures)
* protocol(s) to push this stuff around (currently 2)

Slide 8: Secure Alert Format
----------------------------
* want end-to-end security without relying on layer-2

BR:  There's lots of security properties, but you're lumping them altogether.  You
need integrity protection end-to-end, but maybe not authentication.
RBL: I'm going to argue that's a concern with key distribution, and not the formats.
RBL: To paraphrase for Brian, we want to know the authority that sent the alert
really was who they said they are; and when I travel to Luxembourg, I want to receive
alerts but I don't know how to verify that it's the authority that's sending it to
me?
BR:  Are we sure we need end-to-end, or is hop-to-hop enough?
DC:  That is a very important but very low-level question.  The high-level question
is whether the recipient needs to validate the integrity of the sender.
JP:  There will be multiple distribution authorities
BR:  Again, do we need end-to-end or hop-to-hop?
RBL: That's a good question, but not important yet.  There's some need to sign the
alert format.

Slide 9: Broadcast Reqs
-----------------------
* Deliver msgs in common format so that a device that registers for alerts gets and
* understands the alerts, regardless of the transport.

KD:  I'm going to jump on this slide again.  There could well be a relationship
between distributor and recipient whereby distributor downloaded application to user
when the user registered for the service, and if that was the use case, it required
very little or no standards track activity. Further, in response to a point about
layer two capability, all the discussion in the past had included some form of
subscription or registration to the service, and layer 2 characteristics of the
recipient could be passed from recipient to distributor at that point
.
BR:  the reason that we're not going down that road is because we don't want to be
limited based on the layer-2
RBL: I think there's something like Skype, which is aware of the layer-2 details, but
wants to participate.  We don't want to rely on layer-2 characteristics, but take
advantage of them if we can.  If we were relying on a UDP datagram, the app can
listen for that; if the network knows about this it can broadcast that UDP datagram
content in an optimized manner.
MW:  I think we've got at least two mechanisms that can utilize this.
Scott Bradner:  While that feature is available in some, it's not available in all
BR:  I think there's two ways to do that [the form of the alert]. Can we rely on the
recipient to announce what format it wants, or do we send multiple and the recipient
selects the one they want?
RBL: Let's take location as an example.
BR:  I think we want to handle both.  And we need to find a way to put that into the
CAP message, or wrap multiple CAP messages.

Slide 10: Broadcast Design Principals
-------------------------------------
There's a question on ho

DC:  There's a distinction that needs to be made that hasn't been made yet.  The
distribution is the relaying function, and broadcast is the receiving function.
There's a distinction in what you need in the broadcast stage versus what is needed
in the end-to-end stage.  To incorporate both means you have an explosion of
complexity.
BR:  I understand, but I don't think 
RBL: The notion that I brought up in broadcast that needs to be generalized.
RBL: And we want this registration thing to span across protocols.
BR:  I think we can say that we need to have some of this filtering done on both
sides.  I think we ought to say that the recipient always needs to be able to filter,
but the sender might be able to filter as an optimization

Slide NN: Discussion
--------------------

*  Sounds like we might want to refactor into a high-level transport/registration and
*  a low-level transport.

* Mark Wood:  I'm most interested in the broadcast side of things
* SB:  I think we need to wait for the minutes before we start handing out
* assignments.  This has been a rich discussion that needs more consideration.
* Secure CAP Format, Architecture, but not the rest just yet.
KD:  Will we deal with scaling requirements as part of the architecture discussion.
RBL: We want to 
MW:  In the midst of the emergency, they are already at (or past) the load point of
failure.
MW:  When you are talking about school closings, you're not at the load to the point
of failure, but if you're in an emergency you are.  There might be some things we
want to do that are not scale considered, and some we are.
BR:  There are things we want to work in both large and small scales, but we want as
much commonality between the two as possible.
MW:  Of course when you are dealing with going from single-cast to multi-cast, there
more information you need to convey to get there.  For instance, there are limits on
the number of octets on some transports, so targeting a multi-cast later on means
there's less data you can send in the first place, but if you're targeting a smaller
distribution you can include things like images.
SB:  I think this has been a good discussion, and there's things for the chairs to
decide.
- m&m

Matt Miller - <mamille2 at cisco.com>
Collaboration Software Group - Cisco Systems, Inc.