Re: [atoca] Discovery mechanism

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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