Re: [atoca] Discovery mechanism

[Martin Thomson <[e-mail]>]

<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