Subject: Re: [atoca] Discovery mechanism

From: Matt Lepinski <[email-masked]>
Date: Fri, 04 May 2012 13:10:35 -0400

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 May 2012 11:49:03 -0700

Thanks Matt.

In this example scenario, I can imagine a number of arrangements, with
varying numbers of steps.

In one solution discovery looks like:
 1 look for metadata server using NAPTR
 2 go tell the metadata server everything you care about, server tells
you where to pick up your alerts

Where step 2 might involve several requests as you push different information.

With LoST involved, but still with a metadata server:
 1 look for LoST server (NAPTR again)
 2 tell LoST server what service you care about and the location, LoST
tells you where to go to do discovery
 3 talk to "metadata server" and repeat above

The last option is to use LoST only.  Which would probably involve
extensions to LoST so that you can tell it about more stuff.  (I think
that we may get language already, but I'm not sure.)

One difference in the approaches is whether you tie discovery to the
geography (LoST) or to the network topology (straight NAPTR using the
access network domain as input).

I am inclined to think that we have enough motivation to consider both
approaches.

 - Avoiding LoST for getting first party alerts makes sense because
LoST isn't (necessarily) going to be aware of which network you are
attached to, nor can it make a sensible decision about that from the
outside.  So a "metadata server" probably has a role in this.

 - Using LoST to request alerts that might affect others (alerts for
where my son is), makes a great deal of sense.  I tend to think that
this should simply bootstrap into the "metadata server"
discovery/registration process.

The question that arises is how granular each of these searches is?
Do I search for "urn:service:alerts" or "urn:service:alerts:weather" ?
 I have a strong aversion to taxonomies, so I tend to favour the
former.  I can see how having some granularity at the first step helps
some use cases, but I would prefer to see that sort of separation left
to implementers.

We should talk more about registration later.  Maybe there is a
seamless transition from discovery to registration for those
mechanisms that want it.  That would be acceptable.  I'd like to
retain the logical separation though.

--Martin

On 4 May 2012 10:10, Matt Lepinski <[email-masked]> 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
>
> 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
>
>
>>> 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?
>>
>>> 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.
>>
>>> 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
>>>
>>>> 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.
>>>>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 4 May 2012 15:00:48 -0400

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
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 8 May 2012 18:06:03 -0400

> 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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 8 May 2012 18:15:58 -0400

Yeah, which one you are one, not what type.

It's conceivable that when you discover it and contact it, it may offer you options on delivery, and some of them might be L2 dependent (like, for example, cell broadcast or multicast).  However, the discovery is "how do I find the broadcast server for this network?".

Brian