Re: [atoca] Discovery mechanism

[Matt Lepinski <[e-mail]>]

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