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 - Collaboration Software Group - Cisco Systems, Inc.