[03:49:48] --- pierz has become available
[03:49:52] --- pierz has left
[13:48:37] --- mmealling has become available
[14:50:53] --- dcrocker has become available
[14:56:15] --- Ted_Hardie has become available
[14:56:58] * mmealling waves
[14:56:58] --- dcrocker has left: Disconnected
[14:57:14] --- dcrocker has become available
[14:57:14] --- dcrocker has left: Disconnected
[14:57:37] --- dcrocker has become available
[14:57:37] --- dcrocker has left: Disconnected
[14:58:09] --- dcrocker has become available
[14:58:09] --- dcrocker has left: Disconnected
[14:58:36] --- dcrocker has become available
[14:58:37] --- dcrocker has left: Disconnected
[14:58:38] --- anewton has become available
[14:59:01] --- dcrocker has become available
[14:59:01] --- dcrocker has left: Disconnected
[14:59:02] * anewton waves at mmealling
[14:59:07] <Ted_Hardie> Hi Michael
[14:59:31] --- dcrocker has become available
[14:59:31] --- dcrocker has left: Disconnected
[14:59:43] <mmealling> how's vancouver so far?
[14:59:53] --- dcrocker has become available
[14:59:54] --- dcrocker has left: Disconnected
[15:00:19] --- dcrocker has become available
[15:00:19] --- dcrocker has left: Disconnected
[15:00:26] <anewton> the network is frustrating
[15:00:33] <Ted_Hardie> Marc welcomes the group.
[15:00:38] --- dcrocker has become available
[15:00:38] --- dcrocker has left: Disconnected
[15:01:00] --- dcrocker has become available
[15:01:01] --- dcrocker has left: Disconnected
[15:01:04] <Ted_Hardie> Marc notes Hannes has created an aggressive agenda.
[15:01:06] * mmealling wave at Andy and is slightly surpised to see that Karen let him leave town.
[15:01:31] --- dcrocker has become available
[15:01:31] --- dcrocker has left: Disconnected
[15:01:38] <Ted_Hardie> Hannes presents the status of the group.
[15:02:01] --- dcrocker has become available
[15:02:02] --- dcrocker has left: Disconnected
[15:02:33] --- dcrocker has become available
[15:02:34] --- dcrocker has left: Disconnected
[15:02:56] <Ted_Hardie> Mostly red bullents; the only "problematic" (as opposed to milestone in past) cannot actually be done.
[15:02:56] <Ted_Hardie> No Green
[15:02:56] <Ted_Hardie> He goes into how to proceed.
[15:02:56] <Ted_Hardie> Notes that there has been good technical discussion, on topic, but still having timing issues which require action
[15:03:00] <Ted_Hardie> Lists tools (design team,s phone conferences, trackers) etc.
[15:03:04] --- dcrocker has become available
[15:03:04] --- dcrocker has left: Disconnected
[15:03:24] --- dcrocker has become available
[15:03:24] --- dcrocker has left: Disconnected
[15:03:39] <Ted_Hardie> Asks that people be prepared for these mechanisms of encouraging high bandwidth discussion (conference, interim meeting, etc.)
[15:03:49] <Ted_Hardie> Will discuss further during the week and on the list.
[15:03:53] --- dcrocker has become available
[15:03:54] --- dcrocker has left: Disconnected
[15:04:07] --- dcrocker has become available
[15:04:08] --- dcrocker has left: Disconnected
[15:04:14] <mmealling> http://www.nap.edu/books/0309055407/html/R1.html
[15:04:18] <Ted_Hardie> Now into agenda: open issues in requirement
[15:04:25] --- dcrocker has become available
[15:04:25] --- dcrocker has left: Disconnected
[15:04:43] --- dcrocker has become available
[15:04:43] --- dcrocker has left: Disconnected
[15:04:45] <Ted_Hardie> Agenda bashing invited
[15:04:47] <mmealling> a book by Karen Sollins and the National Academy of Sciences on communications in disaster situations....
[15:04:48] <Ted_Hardie> Brian asks whether the agenda discussion solutions
[15:05:23] <Ted_Hardie> Hannes replies that requirement discussion has to complete to have a solid discussion of solutions
[15:05:26] --- dcrocker has become available
[15:05:34] --- dcrocker has left: Disconnected
[15:05:40] * mmealling nails dcrocker's foot the floor
[15:06:06] --- dcrocker has become available
[15:06:07] --- dcrocker has left: Disconnected
[15:07:38] --- dcrocker has become available
[15:08:21] --- dcrocker has left: Disconnected
[15:08:27] <Ted_Hardie> Brian notes that issues raised on the list will not be discussed
[15:08:27] <Ted_Hardie> Hannes clarifies that the issues raised will be discussed in terms of requirements.
[15:08:27] <Ted_Hardie> Roger Marshall (*editor of requirements editor)
[15:08:27] <Ted_Hardie> requirements update agendum begun
[15:08:27] <Ted_Hardie> Lists issues resolved
[15:08:52] <Ted_Hardie> Open issue 15: Validation of civic location
[15:09:22] --- dcrocker has become available
[15:09:30] <Ted_Hardie> Brian comments that this requirement comes from NENA; it is critical, but not architectural
[15:11:27] <anewton> Henning: bits on the wire does not necessarily mean the address will be validated
[15:11:38] <dcrocker> NENA?
[15:12:51] --- dcrocker has left
[15:13:17] <anewton> Hardie: difference between protocol between address to URI vs. a valid address
[15:13:36] <anewton> NENA is a north american organization that deals with emergency calling issues.
[15:14:33] --- dcrocker has become available
[15:14:42] <dcrocker> ack. tnx.
[15:15:47] <Ted_Hardie> Brian notes that the real requirement is that the address is verified as a valid address *for dispatch*, even if that would not be required for mapping
[15:16:00] <Ted_Hardie> (note that geospatial complicates this)
[15:16:46] <Ted_Hardie> Andy Newton believes that we need to be clear about when this validation occurs (the "prior to its use" might imply just before), when it is an operational issue that might be prior
[15:17:00] <Ted_Hardie> Brian will send additional text in response to this issue
[15:17:16] <Ted_Hardie> Parenthesis above from James Polk
[15:18:06] <Ted_Hardie> Ma9: Traceable resolution: the entity requesting mapping should be about to determine the entity providing the resolution information.
[15:18:16] <Ted_Hardie> Movtvation: traceability
[15:18:41] <Ted_Hardie> Rohan: Requirement is on the eventual deployment
[15:19:07] <Ted_Hardie> Requirement is to be able to provide a way to carry this information
[15:19:24] <Ted_Hardie> Security property of this information is a separate information
[15:19:41] <Ted_Hardie> Brian Rosen: Traceability, not the signature critical to the original requestor
[15:19:55] <Ted_Hardie> (nena again?)
[15:21:06] <Ted_Hardie> Henning believes that the how of this should be discussed in the security document, where object security vs. channel security aspect can be explored in sufficient detail.
[15:21:28] <Ted_Hardie> Hannes asks Rohan for text on his suggestion
[15:21:32] <Ted_Hardie> Roger agrees that security document moves to that document
[15:21:49] <Ted_Hardie> Addendum shows issues listed as minor.
[15:22:09] <Ted_Hardie> New potential requirements flashed---they will go into the tracker
[15:22:52] <Ted_Hardie> Roger confirms Brian's NENA-related issues will be added to the tracker
[15:23:21] <Ted_Hardie> Hannes encourages folks to write things up in issues-style, and notes that folks can add things to the issues tracker themselves.
[15:24:03] <Ted_Hardie> Brian will break them out into specific issues.
[15:24:19] <Ted_Hardie> Marc suggested 2 requirements to the list--seeking wider opinion.
[15:24:32] <Ted_Hardie> LCMS system only deals with location by value (not reference)
[15:25:13] <Ted_Hardie> Is pre-call routing a desirable function?
[15:25:34] <Ted_Hardie> (Note--lcms query in advance of need a useful thing) is a restatement of the statement above.
[15:25:39] <Ted_Hardie> Rohan raises 3 issues
[15:26:03] <Ted_Hardie> 1) List of uris specified--is this opinion of the author, or is this consensus of the group?
[15:26:10] <Ted_Hardie> (Already an open issue--Hannes)
[15:26:41] <Ted_Hardie> 2) Having enough information to provide sufficient information to provide help in 3-d
[15:26:55] <Ted_Hardie> 3) Unmotivated discussion of relays
[15:27:15] <Ted_Hardie> Rohan will send these to the list.
[15:27:32] <Ted_Hardie> Andy's responds to Marc.
[15:27:50] <Ted_Hardie> He doesn't see why we'd want to do by-reference in interactions with the LCMS
[15:28:46] <Ted_Hardie> James Winterbottom expresses a concern about sending an identity (unlinking identity and mapping function)
[15:29:03] <Ted_Hardie> Formal requirement for this desired (in the spirit of 3693)
[15:29:23] <Ted_Hardie> James is asked for mail to the list; he believes he has already done so.
[15:29:31] <Ted_Hardie> He will resend or make a reference.
[15:29:53] <Ted_Hardie> Brian making clear before that he was channeling NENA
[15:30:04] <Ted_Hardie> For himself, he believes that we shouldn't do by reference, and would support James's requirement.
[15:30:21] <Ted_Hardie> For Marc's issue of pre-mapping; he believes it is useful to do so.
[15:30:39] <Ted_Hardie> You should do it again when you have the emergency, but a cached value is better than nothing.
[15:31:04] <Ted_Hardie> If you have connectivity to the psap but not mapping server.
[15:31:21] <Ted_Hardie> Henning argues that the protocol should not be in the business of limiting when it is invoked.
[15:31:24] <Ted_Hardie> That's operation.
[15:32:48] <Ted_Hardie> James Polk agrees with Brian; he has been concerned with discussion over the past couple of months, but he beleives that it generally accessible.
[15:33:04] <Ted_Hardie> Moving on to next presenter
[15:34:06] <Ted_Hardie> Tom Taylor presents Security considerations draft
[15:34:09] <Ted_Hardie> Very funny graph
[15:34:20] <Ted_Hardie> Henning says "render it in ascii, and then you're done"
[15:34:46] <Ted_Hardie> Notes that are threats that are nothing to do with our mandate.
[15:34:59] <Ted_Hardie> Impresonation/malicious dispatch is one such threat.
[15:35:32] <Ted_Hardie> threats: disclosure, targeted dos, mass dos
[15:36:12] --- jean-francois has become available
[15:36:30] <Ted_Hardie> Tom believes some of the threats discussed on the list have different architectural assumption
[15:36:57] <Ted_Hardie> If mapping is done at user configuration time, lowers effectiveness of attack on mapping server; raises likelihood that attack on user client would be effective
[15:37:17] <Ted_Hardie> If mapping is done at call time, mapping server attacks could block calls more easily
[15:37:52] <Ted_Hardie> Tom believes we have to discuss which architectural variant we're talking about for specific threat analyses
[15:38:04] --- dcrocker has left
[15:38:34] <Ted_Hardie> One of the issues: is it worth authenticating the mapping server?
[15:38:50] <Ted_Hardie> if mapping is done at user agent configuration time?
[15:39:07] <Ted_Hardie> if done by user agent at call time? if by a proxy on the call path?
[15:39:24] <Ted_Hardie> Henning: This is a general issue for us to be careful about--what does it mean to authenticate.
[15:39:37] <Ted_Hardie> Are we authenticate the name of the mapping server?
[15:40:02] <Ted_Hardie> Or are we authenticating something about their relationship to some higher authority?
[15:40:34] <Ted_Hardie> Ted: That's authorization to act in a roll, no?
[15:41:26] <Ted_Hardie> Speaker: You should describe and get agreement upon what you want to achieve, then work on what the attacks on that achievement are.
[15:41:43] --- bhoeneis has become available
[15:41:44] <Ted_Hardie> Steve Kent was just speaking
[15:42:14] <Ted_Hardie> Andy Newton says the document goes into threats and requirements to resolve; he likes the current layout of the draft.
[15:43:18] <Ted_Hardie> Jon also disagrees with Steve on this. Use cases are enumerated (these are not exhaustive) and the threats are desribed in those terms
[15:43:35] <Ted_Hardie> Tom says that you do know what you want and don't want to have happen.
[15:44:11] <Ted_Hardie> Hannes replies that we're dealing with cases where the security desiderata are subordinated to the primary emergency call completion.
[15:44:28] <Ted_Hardie> Trade-off has to be considered
[15:45:14] <Ted_Hardie> Jon believes we cannot do security in a vaccum. We have to describe these in realistic terms.
[15:45:36] <Ted_Hardie> Steve says you have to describe what correct operation would look like.
[15:45:54] <Ted_Hardie> If you can't do that, you can't describe what the attacks on correct operation would be.
[15:46:08] <Ted_Hardie> Steve says trade-off considerations come at later stage.
[15:46:37] <Ted_Hardie> He says discarding something as a requirement because you couldn't meet it is cheating.
[15:47:31] <Ted_Hardie> (Notes he hasn't read the document or participated before, but long experience in security says that this is the correct approach)
[15:47:54] <Ted_Hardie> Jon agrees you have to understand correct operation, but does not see a reason to adjust this document's approach at this time.
[15:48:26] <Ted_Hardie> Henning believes that a more general description of how to write security documents is not really where we are, and we should focus on this document.
[15:49:14] <Ted_Hardie> Discussion reverts to slide
[15:49:31] <Ted_Hardie> Hannes says "authorization to act in a role for a location"
[15:50:02] <Ted_Hardie> Henning asks we that we be careful with authenticate/authorize here, because the situation doesn't match classical access issue
[15:50:48] <Ted_Hardie> Can I ascertain who sent it? Can I ascertain that who sent is recognized by some other party for information in general? Can I ascertain that they are recognized by some other party for this information?
[15:51:04] <Ted_Hardie> Do we care about this at all?
[15:51:24] <Ted_Hardie> henning--this is not a protocol or crypto problem. The hard problem is the recognized authority party.
[15:51:53] <Ted_Hardie> We have a way of showing who you are speaking to, but how to determine how would be appropriate for granting this recognition not possible for us.
[15:52:35] <Ted_Hardie> Andy: not useful if limited to "anybody who can buy a cert"
[15:52:48] <Ted_Hardie> Hannes: is this a requirement from PSAP operators?
[15:53:10] <anewton> Richard Statsny: security in the system or threats from outside?
[15:53:54] <anewton> Hannes: most of the requirements are on the mapping protocol.
[15:55:03] <anewton> Rosen: there is not a requirement for a very strong authentication of the mapping data. this is a nice to have and not a requirement.
[15:55:20] <anewton> Jon P: it would be tough to meet this type of requirement.
[15:56:06] <anewton> Jon P: it is not useful to have authentication but if the user of the information cannot do authorization based upon the authentication
[15:56:50] <anewton> henning: we can make progress on this issue if we get away from thinking that end-users will be needing to do authentication.
[15:59:10] <anewton> hardie: mapping client would still use a non signed or invalidly signed answer would still use that answer
[15:59:57] <Ted_Hardie> Jdr: higher layer comment
[16:00:27] <Ted_Hardie> ECRIT has a really hard problem in front of it: solve a problem with extreme requirements (many failure scenarios)
[16:00:45] <Ted_Hardie> He doesn't want us to use that to ignore real potential for harm.
[16:00:52] <anewton> j. rosenberg: ecrit wants to solve a problem where that call always goes through.
[16:00:56] <Ted_Hardie> His particular issue is attacks on the psap
[16:01:17] <Ted_Hardie> It doesn't take much to attack a single psap.
[16:01:46] <anewton> hardie: psaps are valuable resource and we need to protect them
[16:01:49] <Ted_Hardie> He's concerned about how to make the trade-offs to protect the psap, given that they are valuable
[16:02:33] <Ted_Hardie> Speaker: hard to distinguish between real emergency load and dos
[16:03:11] <Ted_Hardie> Jonathan: this does provide a mechanism to pushback on those, by key checking
[16:03:18] <Ted_Hardie> Speaker: Steve Lawrence
[16:03:38] <anewton> rosen: we have to protect psaps. but it is gonna happen and we will need defec
[16:03:49] --- adam has become available
[16:03:50] <Ted_Hardie> Brian: This is a hard balance to maintain, but Brian feels we ought to bias to putting the calls through.
[16:04:02] <Ted_Hardie> (Hannes cuts discussion here, to let us make progress in the room)
[16:04:29] <Ted_Hardie> Brian: this will remain a problem, but the balance has to be sought.
[16:04:34] <Ted_Hardie> Moving on
[16:05:17] <adam> Obligatory kitty cheesecake picture
[16:05:21] <Ted_Hardie> Andy Newton presents on architectural considerations draft
[16:06:01] <Ted_Hardie> Andy believes that one issue is that different network environments give rise to very different views of this.
[16:06:17] <Ted_Hardie> They tried to get to "what does every environment need to support"
[16:06:31] <Ted_Hardie> bootstrapping, conversion, mapping, conveyance
[16:06:57] <Ted_Hardie> bootstrapping--delivery configuration and location information "seekers" (DHCP, PP, LLDP, MANUAL)
[16:07:15] <Ted_Hardie> The ecrit requirements upon bootstrapping are not clear
[16:07:27] <Ted_Hardie> (bootstrapping might provide info or give pointer to mapping server)
[16:08:15] <Ted_Hardie> Conversion: may be conversion of syntax; may also involve geocoding & reverse geocoding
[16:09:16] <Ted_Hardie> Henning asks who is doing the reverse geocoding
[16:09:49] <Ted_Hardie> The draft makes clear that not all aspects of the 4 (bcmc) will be in the mapping protocol; the environment needs to support them.
[16:11:59] <Ted_Hardie> Richard: is it always required to support conversion? If I have a geo address, I use that, right? I don't convert that to civic?
[16:12:11] <Ted_Hardie> Andy notes that this an area of disagreement?
[16:13:28] <Ted_Hardie> Hannes and Andy discuss the importance of this and the weeds are seen. Brain argues that conversion should never be done outside the psap.
[16:13:43] <Ted_Hardie> Hannes asks that we move on during the wg meeting on this.
[16:14:13] <Ted_Hardie> James Polk believes we should discuss this, as it goes to why folks are talking past each other.
[16:14:21] <Ted_Hardie> Andy cuts Jon at the mike.
[16:14:30] <Ted_Hardie> Mapping phase-is the focus of this group.
[16:14:45] <Ted_Hardie> Conveyance--not in this working group. Information sent to the PSAP during the emergency call.
[16:17:19] <Ted_Hardie> Marc asks about static, and clarification that we are talking about static locations, not static mappings (though they may be long lived)
[16:17:35] <Ted_Hardie> Rohan asks about Emergency Call identifiers.
[16:18:03] <Ted_Hardie> He sees things like (fire, rescue, etc.) are characteristics of an identifier "emergency".
[16:18:41] <Ted_Hardie> Hannes and Henning jump in. Henning notes that we have discussed this for a long time.
[16:19:36] <Ted_Hardie> Henning is concerned about the terminology getting muddier here Emergency call identifier moves call strings and protocol identifiers into a lump.
[16:20:39] <Ted_Hardie> henning and Andy agree that there is a problem in different perspectives not converging here.
[16:21:09] <Ted_Hardie> This draft's data distribution and extensibility sections probably solved by rev5 of requirements.
[16:22:04] <Ted_Hardie> conflation---we cannot force inputs to report in ways that are tuned to how ecrit would use them
[16:22:12] --- anewton has left
[16:22:35] <Ted_Hardie> (e.g. if ECRIT uses abbreviations for streets, cannot require inputs to do so; they may use "typical" addresses)
[16:22:45] <Ted_Hardie> Henning gets up to present.
[16:22:57] <Ted_Hardie> Impact of architecture on requirements.
[16:23:45] <Ted_Hardie> seekers-want info; resolvers know >= 1 forest guide (but not trees); forest guides know trees
[16:24:15] <Ted_Hardie> Puts up a slide about the multiple actors in this environment.
[16:24:51] <Ted_Hardie> They don't have the same interests.
[16:25:05] <Ted_Hardie> End users, ISPs, Emergency service authorities, mapping service providers
[16:25:54] <Ted_Hardie> He believes that there is a requirement to accommodate competing and non-cooperative parties
[16:28:02] <Ted_Hardie> We also need to recogned that there are things like national politcs, and there may not be a political root organization.
[16:29:24] <Ted_Hardie> Brian asks how this avoidable, and wonders why the same solutions used by ENUM are not applicable.
[16:29:39] <Ted_Hardie> Henning believes it would be nice to be able to get started without resolving that problem
[16:30:20] <Ted_Hardie> REquirements? End user must be able to perform mapping if mapping functionality is offered by VSP (or other 3rd party)
[16:30:32] <Ted_Hardie> Mapping nodes must be able to refer clients to more appropriate node
[16:30:51] <Ted_Hardie> Different resolution hieirarchies must be able to co-exist.
[16:31:15] <Ted_Hardie> move into a different preso
[16:31:31] <Ted_Hardie> Emergency Service Identifiers
[16:31:52] <Ted_Hardie> The draft has been a bit homeless
[16:32:25] <Ted_Hardie> Motivation: if the resolution needs to be done by a proxy, the proxy must know resolution is required. It is context-dependent resolution.
[16:33:00] <Ted_Hardie> What is available?
[16:33:09] <Ted_Hardie> To header: Request URI, SIP header fields
[16:33:44] <Ted_Hardie> requirements: direct user interface
[16:34:00] <Ted_Hardie> research emergency help in any country
[16:34:05] <Ted_Hardie> Deployable incrementally
[16:34:13] <Ted_Hardie> testable without impacting psap resources
[16:34:26] <Ted_Hardie> backwards-compatible with pstn calling
[16:35:45] <Ted_Hardie> puts up slides of options
[16:35:59] <Ted_Hardie> numbers: there are about 60
[16:36:14] <Ted_Hardie> make up new tel uri
[16:36:21] <Ted_Hardie> make up a sip url parameter
[16:36:36] <Ted_Hardie> special domain
[16:38:23] <adam> Special reserved user portion
[16:38:37] <adam> (e.g. "sip:sos@example.com")
[16:43:40] <adam> Ted expresses concerns around how these solutions might work in incremental deployments
[16:47:32] <Ted_Hardie> Brian believes that this is the easiest practical way to get this off the ground.
[16:48:08] <Ted_Hardie> Henning asks the line to limit discussion
[16:48:42] <Ted_Hardie> rohan asks then, when do we have the discussion about which of these is sensible to do.
[16:49:12] <Ted_Hardie> Rohan says the end user doing the mapping avoids this, as the address is to the psap, not a special-case request for mapping
[16:49:36] <Ted_Hardie> For really early work, he argues, you have to stick to numbers
[16:50:02] <Ted_Hardie> Henning is confused about what deployment scenario is meant here.
[16:50:36] <Ted_Hardie> Rohan asks what the value is supporting the service urn.
[16:51:23] <Ted_Hardie> Brian argues that this is the marking that something is an emergency call, even if you are calling to the psap.
[16:52:37] --- adam has left
[16:52:51] <Ted_Hardie> Why a URN is put up.
[16:53:24] <Ted_Hardie> urn:service:sname.subsname urn:service:sos
[16:53:41] <Ted_Hardie> (I wonder if folks understand the restrictions on URN syntax?)
[16:54:12] <Ted_Hardie> Goes into UAC requirements
[16:54:26] <Ted_Hardie> Re-enforces that dial strings are not the same as the protocol element here.
[16:54:28] --- adam has become available
[16:54:53] <Ted_Hardie> sos url (at least one proxy needs to understand the convention0
[16:55:28] <Ted_Hardie> Henning suggests we allow both urn:service and sip:sos convention
[16:57:00] <Ted_Hardie> Steve Kent asks about distinction between emergency number and protocol element; clarification provider
[16:57:19] <Ted_Hardie> Jonathan provides clarification.
[16:57:57] <Ted_Hardie> Jonathan believes that the URN service will be what is used in the phone's dial plan
[16:58:47] <Ted_Hardie> Brian can't think of a retarget, but can think of refer (Mom, I'm bleeding--refer to 911).
[16:58:50] <Ted_Hardie> That works fine.
[16:59:10] <Ted_Hardie> (Poison control centers may forward to 911, I believe)
[17:03:02] --- jean-francois has left
[17:03:51] --- bhoeneis has left: Logged out
[17:07:39] --- Ted_Hardie has left: Logged out
[17:08:19] --- adam has left
[17:09:05] --- adam has become available
[17:10:13] --- adam has left
[17:38:40] --- mmealling has left