Re: [atoca] Discovery mechanism

[Brian Rosen <[e-mail]>]

I think you can't get all alerts from one server.

You might get a class of alerts targeted to some geographic server from a server, but if you wanted alerts from some other area (my "send me alerts affecting my daughter"), you probably wouldn't get them from the same server that sends alerts to you based on your own location.
You may also get alerts that are not geotargeted at all, but are just opt-in, everyone who opts in gets them.

Some "discovery" could just be a URI you obtain from some out of band mechanism - email for example.  Easy, but we should document it.

The ones that are geotargeted come in the two flavors (where I am and where someone else is).
The former really probably is L2 dependent, a broadcast server where the L2 geotargets at some level.   The latter is LoST like - I have the location I am interested in as well as the type of alert, and I need to find the server who has those alerts at that location.

So, I'm seeing three discovery "mechanisms"
1. A URI I get from, e.g. email
2. An L2 dependent "find my local broadcast server", which could be DHCP or could reverse DNS a la LIS discovery
3. A geolocation dependent "find some other server based on location" which is LoST or something like LoST.

Brian
On May 4, 2012, at 1:10 PM, Matt Lepinski wrote:

> Martin,
> 
> I agree with you that we need more discussion of what requirements/scenarios for discovery that we need to support. I like your list of information that might be used as input for discovery, but I don't have a clear picture of what a general multi-step discovery process would look like (this is, of course, why the discovery text in atoca-meta is incomplete/insufficient).
> 
> In particular, let's say I turn on my tablet and connect to the local Wi-Fi network. I know I'm on an 802.11 network and I know something about the access point I'm attached to. I roughly know my location and I know my language preference (English) and the protocols I support (e.g., XMPP, SIP, and LEAP).  I want to find a source for weather alerts for my region, how do I go about this? How similar is this to the case where I connect my device to a 3G network and want weather alerts via either SIP or Cell Broadcast?
> 
> The approach sketched in atoca-meta is for the access network to put NAPTR records in the DNS that point my device towards a "metadata server" that knows about lots of alert sources for the area served by my access network. However, I realize this doesn't work in all cases. Is it reasonable to try to you LoST to find a source of alerts for a given alert type (urn)? What else could we consider trying?
> 
> I am not convinced that registration as a function is completely a function of the delivery mechanism. I believe the working group is capable of specifying something useful in the registration space that is applicable to a variety of (although perhaps not all possible) delivery mechanisms. However, I believe this is a separate discussion and I'd rather spend our energy trying to get discovery nailed down first
> 
> I have refreshed the individual draft-barnes-atoca-meta to keep it from expiring, but the content is still unchanged from Paris. However, if we can make some progress on discovery on the list, the authors of atoca-meta would be happy to re-write that document to provide a better basis for discussions in Vancouver.
> 
> - Matt Lepinski
> 
> On 4/5/2012 7:34 PM, Martin Thomson wrote:
>> <bare-headed>
>> 
>> It's become clear to me that what has been lacking in the discovery
>> space is a clear enumeration of the information that I might use as
>> input.
>> 
>> The non-exhaustive list, that I think we need to include in requirements is:
>> 
>>  - network attachment properties (type of network, where on the network, etc...)
>>  - location
>>  - language preference
>>  - protocol support (XMPP, SIP, ATOM, Cell broadcast, LEAP, etc...)
>>  - the alert type of interest
>> 
>> An alert source is as specific as it needs to be.  There may be cases
>> where language preferences have no impact on discovery because alerts
>> are multilingual.  Similarly, it might be true that your network
>> attachment or location is irrelevant to the specific scenario.
>> 
>> Aside from doing a complete end-run around discovery (go straight to
>> the source, use a search engine), there seem to be different
>> "discovery" scenarios, each of which have multiple steps.
>> 
>> atoca-meta really only has one discovery step : (U-)NAPTR records.
>> The protocol it describes conflates two things: discovery and
>> registration.
>> 
>> By taking on registration, meta goes too far.  Registration is a
>> function of the delivery mechanism.  Cell broadcast doesn't need
>> registration.  Source-Specific Multicast subscription is a
>> registration step that would be necessary if delivery used SSM; why
>> have another step?
>> 
>> Sure, meta could treat a registration as a no-op, but by requiring a
>> protocol of this form it inherently sidesteps much of the HTTP
>> infrastructure that is critical for scaling such a service.  In
>> particular, distributed caching.
>> 
>> --Martin
>> 
>> On 30 March 2012 10:40, Art Botterell<[e-mail]>  wrote:
>>> This strikes me as a very worthwhile project.  A couple of quick notes:
>>> 
>>> 1) Might the definitions section include a definition for an "alert source"?  If only to disambiguate between the function of the AMP server and an actual alert "feed" or whatever?
>>> 
>>> 2) If I'm reading this correctly it seems like all we're attempting so far is to get from a general domain to a specific alert source URL.  Useful, I suppose... although it seems much the same thing could be achieved by conventionalizing a prefix like "alerts." (on the pattern of "www." for http servers... but why stop there?  Wouldn't it be useful to enable folks to discover alert sources serving a geospatial location or polygon?  And/or sources that provide certain types of information, as per the CAP "category" element?
>> Conventions like this are considered bad in the IETF.  That's not to
>> say that this wouldn't happen anyway.  I wouldn't want to hang a
>> critical protocol function off a convention though.
>> 
>>> 3) Does the proposed discovery mechanism provide information as to the specific protocol, access controls, etc. implemented by a particular alert source?  E.g., many of the interfaces are ATOM or RSS feeds, but some are in the form of various styles of web service queries.
>> Access control is almost strange, but it's probably something worth
>> including in the description.  Perhaps it would be sufficient to say
>> that it exists, without going into details.
>> 
>>> 4) I'm confused a bit... and maybe this is related to #3... by the inclusion of the Alert type message.  Is it intended that the discovery system also serve as a pub/sub broker for actual alerts?  Seems like that's a bit of a drift from the core... and IMHO, crucial... function of alert source discovery.  And possibly a bit of an overlap with what Google's doing at http://alert-hub.appspot.com/ ?
>> I agree, see above.
>> 
>>> Apologies if I'm asking anything too ignorant here.  Again, I think the basic question of discovery mechanisms is really important.
>>> 
>>> - Art
>>> 
>>> On Mar 30, 2012, at 4:32 AM, Richard L. Barnes wrote:
>>> 
>>>> Hey all,
>>>> 
>>>> As I said in the meeting today, I've put together a proposed mechanism for discovering alert servers.  Much like Brian said today, it's based on HTTP, but can bootstrap out of DHCP and/or LoST.
>>>> 
>>>> Alert Metadata Protocol (AMP)
>>>> <http://tools.ietf.org/html/draft-barnes-atoca-meta-01>
>>>> 
>>>> Reviews welcome!
>>>> 
>>>> Thanks,
>>>> --Richard
>>>> _______________________________________________
>>>> atoca mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/atoca
>>> _______________________________________________
>>> atoca mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/atoca
>> _______________________________________________
>> atoca mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/atoca
> 
> _______________________________________________
> atoca mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/atoca