Re: [atoca] Discovery mechanism

["Richard L. Barnes" <[e-mail]>]

> 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

Note that neither of those mechanisms are dependent on the L2 access type.  So I guess by "L2 dependent" you mean, "Depending on which access network you're connected to", as opposed to, "Which type of access network you're connected to".  Right?

--Richard


> 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
> 
> _______________________________________________
> atoca mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/atoca