From mlepinski@bbn.com Fri May 4 10:10:21 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169B221E803D for ; Fri, 4 May 2012 10:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ufrf4c+EJNsk for ; Fri, 4 May 2012 10:10:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4917821E8034 for ; Fri, 4 May 2012 10:10:19 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:51372) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SQM0u-000E8d-OS for atoca@ietf.org; Fri, 04 May 2012 13:09:52 -0400 Received: from [128.89.254.44] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SQM1I-0004sp-Rc for atoca@ietf.org; Fri, 04 May 2012 13:10:17 -0400 Message-ID: <4FA40D8B.8070402@bbn.com> Date: Fri, 04 May 2012 13:10:35 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: atoca@ietf.org References: <4F7599D8.1010107@bbn.com> <351A6DE9-1BC4-48D4-A8FE-1738F8657EE1@incident.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [atoca] Discovery mechanism X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 17:10:21 -0000 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: > > > 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 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) >>> >>> >>> Reviews welcome! >>> >>> Thanks, >>> --Richard >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From martin.thomson@gmail.com Fri May 4 11:49:06 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909B621F8575 for ; Fri, 4 May 2012 11:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqiB-4Gbl5pa for ; Fri, 4 May 2012 11:49:05 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0549921F856F for ; Fri, 4 May 2012 11:49:04 -0700 (PDT) Received: by bkty8 with SMTP id y8so2952513bkt.31 for ; Fri, 04 May 2012 11:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VGiHjltUQ24SWv9oKQhe4Cy5Siby76hyNiGN9Z7mev8=; b=RkZGdo7RtNE/8EGAZPf9LMRCqN6I3kW7GZpPoSMdH7qDv5CcCXx1tlpa+tN3e3tmbO YhkP1aAhw+IHkaOZXcDRTfNWm6Qh2xAy4UEAGmQzffTxGO4KbRR49VEihYbuNqg6DgiL a6AR3TTdFTBCb5VJInQB63UWdyXtblmjDlUnQIYWfp1ArXFvX4s9zK4qwpFZagSar8Q+ uHpB1S/1P9HAUDW/3UuGKh0lsxz604A/n2yg23gucG+wXI+v9Q08MG0EFrfpuzeaVUDr Bg9Czh/1iMaSgEaNVr+ClJr+lF0/LXV6EY0/jag7kyl//1qM5itx6UkeMigkfZuLGwaI aB0Q== MIME-Version: 1.0 Received: by 10.204.150.84 with SMTP id x20mr1216917bkv.26.1336157344056; Fri, 04 May 2012 11:49:04 -0700 (PDT) Received: by 10.204.185.205 with HTTP; Fri, 4 May 2012 11:49:03 -0700 (PDT) In-Reply-To: <4FA40D8B.8070402@bbn.com> References: <4F7599D8.1010107@bbn.com> <351A6DE9-1BC4-48D4-A8FE-1738F8657EE1@incident.com> <4FA40D8B.8070402@bbn.com> Date: Fri, 4 May 2012 11:49:03 -0700 Message-ID: From: Martin Thomson To: Matt Lepinski Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: atoca@ietf.org Subject: Re: [atoca] Discovery mechanism X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 18:49:06 -0000 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 informati= on. 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 wrote: > Martin, > > I agree with you that we need more discussion of what requirements/scenar= ios > for discovery that we need to support. I like your list of information th= at > 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, SI= P, > and LEAP). =C2=A0I 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 devic= e > 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 NAPT= R > 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 networ= k. > However, I realize this doesn't work in all cases. Is it reasonable to tr= y > 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 functi= on > 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 c= an > make some progress on discovery on the list, the authors of atoca-meta wo= uld > be happy to re-write that document to provide a better basis for discussi= ons > in Vancouver. > > - Matt Lepinski > > > On 4/5/2012 7:34 PM, Martin Thomson wrote: >> >> >> >> 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: >> >> =C2=A0- network attachment properties (type of network, where on the net= work, >> etc...) >> =C2=A0- location >> =C2=A0- language preference >> =C2=A0- protocol support (XMPP, SIP, ATOM, Cell broadcast, LEAP, etc...) >> =C2=A0- the alert type of interest >> >> An alert source is as specific as it needs to be. =C2=A0There may be cas= es >> where language preferences have no impact on discovery because alerts >> are multilingual. =C2=A0Similarly, 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. =C2=A0Registration is a >> function of the delivery mechanism. =C2=A0Cell broadcast doesn't need >> registration. =C2=A0Source-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. =C2=A0In >> particular, distributed caching. >> >> --Martin >> >> On 30 March 2012 10:40, Art Botterell =C2=A0wrote: >>> >>> This strikes me as a very worthwhile project. =C2=A0A couple of quick n= otes: >>> >>> 1) Might the definitions section include a definition for an "alert >>> source"? =C2=A0If 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. =C2= =A0Useful, >>> 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? =C2=A0Wouldn't it be useful to enable fo= lks to >>> discover alert sources serving a geospatial location or polygon? =C2=A0= And/or >>> sources that provide certain types of information, as per the CAP "cate= gory" >>> element? >> >> Conventions like this are considered bad in the IETF. =C2=A0That's not t= o >> say that this wouldn't happen anyway. =C2=A0I 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 al= ert >>> source? =C2=A0E.g., many of the interfaces are ATOM or RSS feeds, but s= ome 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. =C2=A0Perhaps it would be sufficient to sa= y >> 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. =C2=A0Is it intended that the disc= overy >>> system also serve as a pub/sub broker for actual alerts? =C2=A0Seems li= ke that's >>> a bit of a drift from the core... and IMHO, crucial... function of aler= t >>> source discovery. =C2=A0And possibly a bit of an overlap with what Goog= le's doing >>> at http://alert-hub.appspot.com/ ? >> >> I agree, see above. >> >>> Apologies if I'm asking anything too ignorant here. =C2=A0Again, I thin= k 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. =C2=A0Much like Brian said today, it's = based on >>>> HTTP, but can bootstrap out of DHCP and/or LoST. >>>> >>>> Alert Metadata Protocol (AMP) >>>> >>>> >>>> Reviews welcome! >>>> >>>> Thanks, >>>> --Richard >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>> >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >> >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca > > > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From br@brianrosen.net Fri May 4 12:01:34 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8305721F859A for ; Fri, 4 May 2012 12:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cg2mrIwaQfq for ; Fri, 4 May 2012 12:01:33 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.236]) by ietfa.amsl.com (Postfix) with ESMTP id 19E2B21F844E for ; Fri, 4 May 2012 12:01:33 -0700 (PDT) X-ASG-Debug-ID: 1336158051-05376a26e750120001-FTS53d Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id jr6JJlf2DWUPLwPC; Fri, 04 May 2012 12:00:51 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[156.154.4.14]) by wwh1.winweblinux.com with esmtpa (Exim 4.69) (envelope-from ) id 1SQNkJ-002Gp3-54; Fri, 04 May 2012 12:00:51 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [atoca] Discovery mechanism Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <4FA40D8B.8070402@bbn.com> Date: Fri, 4 May 2012 15:00:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7599D8.1010107@bbn.com> <351A6DE9-1BC4-48D4-A8FE-1738F8657EE1@incident.com> <4FA40D8B.8070402@bbn.com> To: Matt Lepinski X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1336158051 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.95992 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: atoca@ietf.org Subject: Re: [atoca] Discovery mechanism X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:01:34 -0000 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, >=20 > 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). >=20 > 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? >=20 > 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? >=20 > 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 >=20 > 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. >=20 > - Matt Lepinski >=20 > On 4/5/2012 7:34 PM, Martin Thomson wrote: >> >>=20 >> 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. >>=20 >> The non-exhaustive list, that I think we need to include in = requirements is: >>=20 >> - 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 >>=20 >> 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. >>=20 >> 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. >>=20 >> atoca-meta really only has one discovery step : (U-)NAPTR records. >> The protocol it describes conflates two things: discovery and >> registration. >>=20 >> 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? >>=20 >> 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. >>=20 >> --Martin >>=20 >> On 30 March 2012 10:40, Art Botterell wrote: >>> This strikes me as a very worthwhile project. A couple of quick = notes: >>>=20 >>> 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? >>>=20 >>> 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. >>=20 >>> 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. >>=20 >>> 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. >>=20 >>> Apologies if I'm asking anything too ignorant here. Again, I think = the basic question of discovery mechanisms is really important. >>>=20 >>> - Art >>>=20 >>> On Mar 30, 2012, at 4:32 AM, Richard L. Barnes wrote: >>>=20 >>>> Hey all, >>>>=20 >>>> 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. >>>>=20 >>>> Alert Metadata Protocol (AMP) >>>> >>>>=20 >>>> Reviews welcome! >>>>=20 >>>> Thanks, >>>> --Richard >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From rbarnes@bbn.com Tue May 8 15:06:09 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F5721F8542 for ; Tue, 8 May 2012 15:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQJY4gkd3bRj for ; Tue, 8 May 2012 15:06:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1930021F8541 for ; Tue, 8 May 2012 15:06:07 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:59329) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SRsXK-000Bry-MF; Tue, 08 May 2012 18:05:38 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 8 May 2012 18:06:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <704C0784-ACD0-432F-A7B0-B1D1F48E0EC0@bbn.com> References: <4F7599D8.1010107@bbn.com> <351A6DE9-1BC4-48D4-A8FE-1738F8657EE1@incident.com> <4FA40D8B.8070402@bbn.com> To: Brian Rosen X-Mailer: Apple Mail (2.1257) Cc: atoca@ietf.org Subject: Re: [atoca] Discovery mechanism X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 22:06:09 -0000 > 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. >=20 > Brian > On May 4, 2012, at 1:10 PM, Matt Lepinski wrote: >=20 >> Martin, >>=20 >> 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). >>=20 >> 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? >>=20 >> 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? >>=20 >> 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 >>=20 >> 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. >>=20 >> - Matt Lepinski >>=20 >> On 4/5/2012 7:34 PM, Martin Thomson wrote: >>> >>>=20 >>> 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. >>>=20 >>> The non-exhaustive list, that I think we need to include in = requirements is: >>>=20 >>> - 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 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> atoca-meta really only has one discovery step : (U-)NAPTR records. >>> The protocol it describes conflates two things: discovery and >>> registration. >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>> --Martin >>>=20 >>> On 30 March 2012 10:40, Art Botterell wrote: >>>> This strikes me as a very worthwhile project. A couple of quick = notes: >>>>=20 >>>> 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? >>>>=20 >>>> 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. >>>=20 >>>> 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. >>>=20 >>>> 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. >>>=20 >>>> Apologies if I'm asking anything too ignorant here. Again, I think = the basic question of discovery mechanisms is really important. >>>>=20 >>>> - Art >>>>=20 >>>> On Mar 30, 2012, at 4:32 AM, Richard L. Barnes wrote: >>>>=20 >>>>> Hey all, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Alert Metadata Protocol (AMP) >>>>> >>>>>=20 >>>>> Reviews welcome! >>>>>=20 >>>>> Thanks, >>>>> --Richard >>>>> _______________________________________________ >>>>> atoca mailing list >>>>> atoca@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/atoca >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From br@brianrosen.net Tue May 8 15:16:03 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BB99E8001 for ; Tue, 8 May 2012 15:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1V7ueMc-WSg for ; Tue, 8 May 2012 15:16:01 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id D50569E800B for ; Tue, 8 May 2012 15:16:01 -0700 (PDT) X-ASG-Debug-ID: 1336515360-05376a130d76bf0001-FTS53d Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id ZdHuXNkWrTBFKAjF; Tue, 08 May 2012 15:16:00 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:24438 helo=[156.154.4.18]) by wwh1.winweblinux.com with esmtpa (Exim 4.77) (envelope-from ) id 1SRshM-001461-6S; Tue, 08 May 2012 15:16:00 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [atoca] Discovery mechanism Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <704C0784-ACD0-432F-A7B0-B1D1F48E0EC0@bbn.com> Date: Tue, 8 May 2012 18:15:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3BFAC343-FE68-489D-A2D0-15AB0B2F0B62@brianrosen.net> References: <4F7599D8.1010107@bbn.com> <351A6DE9-1BC4-48D4-A8FE-1738F8657EE1@incident.com> <4FA40D8B.8070402@bbn.com> <704C0784-ACD0-432F-A7B0-B1D1F48E0EC0@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1336515360 X-Barracuda-URL: http://64.34.111.239:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.96386 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: atoca@ietf.org Subject: Re: [atoca] Discovery mechanism X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 22:16:03 -0000 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 On May 8, 2012, at 6:06 PM, Richard L. Barnes wrote: >> 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 >=20 > 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? >=20 > --Richard >=20 >=20 >> 3. A geolocation dependent "find some other server based on location" = which is LoST or something like LoST. >>=20 >> Brian >> On May 4, 2012, at 1:10 PM, Matt Lepinski wrote: >>=20 >>> Martin, >>>=20 >>> 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). >>>=20 >>> 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? >>>=20 >>> 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? >>>=20 >>> 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 >>>=20 >>> 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. >>>=20 >>> - Matt Lepinski >>>=20 >>> On 4/5/2012 7:34 PM, Martin Thomson wrote: >>>> >>>>=20 >>>> 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. >>>>=20 >>>> The non-exhaustive list, that I think we need to include in = requirements is: >>>>=20 >>>> - 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 >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> atoca-meta really only has one discovery step : (U-)NAPTR records. >>>> The protocol it describes conflates two things: discovery and >>>> registration. >>>>=20 >>>> 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? >>>>=20 >>>> 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. >>>>=20 >>>> --Martin >>>>=20 >>>> On 30 March 2012 10:40, Art Botterell wrote: >>>>> This strikes me as a very worthwhile project. A couple of quick = notes: >>>>>=20 >>>>> 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? >>>>>=20 >>>>> 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. >>>>=20 >>>>> 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. >>>>=20 >>>>> 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. >>>>=20 >>>>> Apologies if I'm asking anything too ignorant here. Again, I = think the basic question of discovery mechanisms is really important. >>>>>=20 >>>>> - Art >>>>>=20 >>>>> On Mar 30, 2012, at 4:32 AM, Richard L. Barnes wrote: >>>>>=20 >>>>>> Hey all, >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Alert Metadata Protocol (AMP) >>>>>> >>>>>>=20 >>>>>> Reviews welcome! >>>>>>=20 >>>>>> Thanks, >>>>>> --Richard >>>>>> _______________________________________________ >>>>>> atoca mailing list >>>>>> atoca@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>> _______________________________________________ >>>>> atoca mailing list >>>>> atoca@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/atoca >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20