[07:24:54] --- anewton has become available
[07:26:59] --- anabolism has become available
[07:29:30] <anewton> hello Randy.
[07:29:47] --- hardie has become available
[07:29:57] <anabolism> Hi Andy
[07:30:09] <hardie> hi Randy
[07:30:20] <hardie> Okay if I mute you on my computer?
[07:30:34] --- hardie has left
[07:31:58] <anabolism> hi
[07:32:06] <anabolism> I'm on the bridge
[07:32:14] <anabolism> there is a radio or tv on the bridge ???
[07:32:36] <anabolism> Ted, go ahead and mute
[07:35:00] --- hardie has become available
[07:40:30] <anabolism> I can't hear whomever is speaking on the bridge, even with my phone volume cranked
[07:41:02] <anewton> it is the host introducing the facilities. I don't think you'll need to know where the restrooms are.
[07:41:16] <anabolism> ah, thanks
[07:42:55] <anewton> hannes is going over the agenda
[07:43:33] <anewton> requirements, threats, emergency identifiers: sipping SOS/ service URI, mapping protocol proposals and architecture considerations, location conveyance, miscellaneious
[07:44:18] <anewton> hannes will be putting slides at www.ietf-ecrit.org.
[07:45:40] <anewton> re location conveyance draft, Brian Rosen says it has been recently discussed in SIP WG. Putting here is probably not a bad idea.
[07:46:14] <anewton> Jon P: it has applicability outside emergency services. largely orthogonal to this work
[07:46:59] <anewton> hannes: if time permits, I'd like to discuss it.
[07:47:11] <anewton> Brian: what are we doing? moving it forward here?
[07:47:18] <anewton> Hannes: we are just talking about it
[07:47:29] <anewton> Jon: to discuss if it meets our requirements?
[07:47:36] <anewton> Brian: yes
[07:48:11] <anewton> hannes: milestone discussion (bleck!)
[07:48:23] <anewton> Brian: good agenda item to have
[07:48:58] <anewton> andy: what about Henning's arch draft?
[07:49:07] <anewton> Henning: I have prepared something
[07:50:13] <anewton> agenda modified to have architecture first
[07:50:40] <anewton> Brian: that is what I wanted to talk about re: milestone
[07:50:52] <anewton> Henning: probably important to have before identifier discussion
[07:50:58] <anewton> hannes: agrees to agenda bash
[07:53:04] <anewton> roger now doing requirements
[07:53:24] <anewton> roger: issue 15 re validation of civic
[07:53:39] <anewton> andy: I thought the list left the issue not about not doing it, but how.
[07:53:46] <anewton> roger: need to know about the language in the draft
[07:54:08] <anewton> brian: something about a way to do it
[07:54:24] <anewton> jon: related to other req. such as querying it anywhere.
[07:54:37] <anewton> james p.: we are no validating
[07:54:56] <anewton> ted: text in the issue tracker is not the meaning of validation in NENA, etc...
[07:55:12] <anewton> ted: this is a valuable piece of protocol machinery.
[07:55:39] <anewton> james: that makes sense, but the text doesn't say that
[07:56:03] <anewton> brian: if validation is defined as succesful mapping to the PSAP, then that is what we want.
[07:56:11] <anewton> james: need other word than "valid"
[07:56:28] <anewton> brian: what we have can be used for NENA view of the world
[07:57:01] <anewton> james: anything out of this building to the proper PSAP, but not floor by floor
[07:57:16] <anewton> brian: the requirement is to know that you can send a responder.
[07:57:32] <anewton> marc: not sure that is the NENA view, re ESN
[07:58:04] <anewton> brian: the location is knowing we can send a responder
[07:58:09] <anewton> nadine: agree
[07:58:52] <anewton> brian: definition of valdiation to be successful mapping to occur for the location
[07:59:10] <anewton> ted: this requirement needs the point brian is making
[07:59:49] <anewton> james: concerned with people thinking we mean something much more precise
[08:00:12] <anewton> hannes: the definition does not match the requirmenet
[08:00:26] <anewton> roger: let's examine the definition first
[08:01:09] <anewton> nadine & brian: this is a good defintion
[08:01:15] <anewton> james: no, that is cumbersome
[08:03:04] <anewton> henning: problem is that this is trying to define validation for both civic and geo. first test is syntactic validity. the description is not clear if the actual address exists.
[08:03:49] <anewton> henning: second test, is there a valid mapping, third, is there a street address that can be routed to.
[08:04:14] <anewton> brian: clarifying this is a good idea.
[08:04:21] <anewton> nadine: agree with 1 and 2, but not 3
[08:04:27] <anewton> roger: we cannot achieve 3
[08:04:38] <anewton> henning: then we need to be clear about it
[08:05:36] <anewton> roger: "but not equivicate to an address" ?
[08:05:58] <anewton> brian: add new sentence to clarify it. "while desirable to have the address exist, not guarnateed."
[08:06:46] <anewton> ted: wandering from the protocol requirement. an address could be invalid for other purposes but could get mapped to a PSAP.
[08:07:46] <anewton> ted: could I give you a PSAP based on the location given, if answer is yes then that is the one thing we care about
[08:08:01] <anewton> henning: just need a qualification of what it does not mean
[08:08:42] <anewton> brian: agree, see my previous wording
[08:09:17] <anewton> marc: mentions some use case in Texas.
[08:09:25] <anewton> brian: but that is not how it will work
[08:09:40] <anewton> marc: but if the address does not exist, no PSAP
[08:09:46] <anewton> brian: that is making an assumption
[08:10:35] <anewton> brian: current MSAG does address ranges, but we should have ability in future to work on single addresses
[08:11:07] <anewton> marc: do you believe it shouldn't return an answer?
[08:11:10] <anewton> brian: ?
[08:11:41] <anewton> ted: in some administrations, the answer will be "here is your PSAP, and btw the address you gave is foobar"
[08:13:18] <anewton> nadine: be able to distinguish if it is the "right" PSAP vs "default" PSAP?
[08:13:47] <anewton> ted: for validation it would be "right".
[08:14:33] <anewton> henning: this has implication on protocol design choices.
[08:15:57] <anewton> henning: difference in use case in validation and non-validation (emergency case) and the bits on the wire in the protocol
[08:16:00] <anabolism> If the case is that the address is 125 main street, and 124 and 126 exist but 125 does not, would validation indicate that the address is syntactically valid, the psap returned would be for 124 and/or 126?
[08:17:19] <anewton> are you asking a question for the room?
[08:17:36] <anabolism> yes, but we've moved on abit
[08:18:06] <anabolism> I was trying to clarify comments from several people
[08:19:21] <anewton> brian: answering randy's q: "I can map it, but it isn't really valid. But in an emergency, it would send you to the closest PSAP."
[08:19:32] <anabolism> Thanks, sounds reasonable to me
[08:19:46] <anewton> marc: result should be saying there is a problem in XML
[08:19:51] <anewton> brian: yes
[08:20:12] <anewton> brian: it is desirable to say you can get a mapping, but there is a problem with the address.
[08:21:20] <anewton> henning: even in a real emergency query, this is nothing wrong with indicating that the address is foobar as long as the PSAP is returned
[08:22:11] <anewton> ted: in a real emergency only look at the one thing they map on. validation may be a different task.
[08:22:47] <anewton> brian: but that work for you
[08:22:56] <anewton> ted: that is why this is desirable.
[08:23:04] <anewton> nadine: ?
[08:23:17] <anewton> nadine: if you only know that it is a known range
[08:24:34] <anewton> andy: just need to make sure that implementers don't let the error show up in the emergency case
[08:24:58] <anewton> roger: do we agree that in addition to the URL that it is desirable to have a result code?
[08:25:10] <anewton> henning: generally, yup/
[08:25:27] <anewton> is the audio being recorded?
[08:26:10] <anewton> henning: it is more than a status code
[08:26:16] <anewton> roger: additional information?
[08:27:13] <anewton> hannes: Validation Resolution: it MAY be possible to return additional information which can be used to determine the preceision or resolution of the returned sip uri, for example
[08:27:28] <anewton> ted: it is not the uri itself, but the elements used to generate the mapping.
[08:27:47] <anewton> james: must, may?
[08:28:00] <anewton> brian: protocol must have mechanism, but this may be used
[08:28:31] <anewton> henning: re 2119 language in the requirements
[08:29:43] <anewton> jon: that is how it is commonly used
[08:29:49] <anewton> andy: not always clear
[08:30:05] <anewton> tom: but that is the way the language is typical used
[08:30:16] <anewton> henning: but we need to clarify.
[08:31:22] <anewton> james: must use SHOULD
[08:31:28] <anewton> andy: not good enough
[08:32:00] <anewton> henning: neither MUST or SHOULD mean it must be implemented or used
[08:32:37] <anewton> tom: experiences elsewhere, requirements can be satisfied with extensibility
[08:34:39] <anewton> henning: parsing language on MUST, SHOULD, MAY on protocol implementation, and then language on MUST, SHOULD, MAY on usage
[08:35:55] <anewton> henning: 2119 language should be used for protocol requirements, lowercase language for usage.
[08:36:37] <anewton> randy: it is confusing to do that. it is not uncommon for RFCs to say MUST implement but MAY use
[08:36:56] <anewton> ted: use 2119 language and be specific
[08:36:59] <anewton> nadine: agree
[08:37:07] <anewton> roger: avoids a rewrite
[08:37:35] <anewton> henning: language is "MUST support"? need some sort of standard terminology
[08:38:41] <anewton> hannes: security doc is a special
[08:38:46] <anewton> andy: agree with randy
[08:39:06] <anewton> henning: we need to be consistent and somebody needs to go through doc and make sure it is clear
[08:39:51] <anewton> roger: I am willing to audit the document, BUT... need review from others
[08:41:31] <hardie> Tom notes that his initial flight got cancelled, and he'll be arriving late; that means that the security discussion should move until after 4:30, when he'll arrive.
[08:42:34] <hardie> Nadine suggests an addition to the requirement. She suggests that the protocol requirement is "MUST support" the ability to indicate issues with the address
[08:43:54] <hardie> The protocol must have a mechanism to indicate that a location or a part of a location is known not to exist even a valid mapping can be provided.
[08:44:00] <hardie> is Brian's text
[08:44:32] <hardie> James asks whether this implies a question about whether returning which pieces are invalid.
[08:46:06] <hardie> Andy says that in some cases it may be best to have an unstructured field, as some pieces of info may be difficult to determine (is it a bad address on elm street, or are you on elm ave)
[08:47:17] <hardie> Barbara asks about the issue of ranges where you do not have a knowledge about a specific element in the range.
[08:47:49] <hardie> Brian responds that his choice of "known invalid" was deliberate, as there isn't much you can do with that in cases like elements in a range
[08:48:18] <hardie> James asks about conflicts with language on sending
[08:48:39] <anewton> people on the phone:
[08:49:13] <anewton> roger: summarize lo1, change defintion, added new reqs in lo section
[08:49:45] <anewton> roger: editor to audit MUST, MAY, SHOULD on protocol requriements vs. usage requirements
[08:51:06] <anewton> people on the phone: barbara star, nadine abbot, randy gellens, patty mccalmont, ron waero
[08:53:01] <anewton> issue 17
[08:53:46] <anewton> brian: need a way to report that it is wrong. there needs to be one way to do it
[08:54:01] <anabolism> Very big font, Andy
[08:54:17] <anewton> so that the room can read what is on the screen
[08:54:36] <anewton> test
[08:55:28] <anewton> henning: do we need a standard error mechanism or would it be helpful to have a URL to say there is a problem
[08:56:09] <anewton> nadine: works with discussion in NENA
[08:56:22] <anewton> tom: something about error flags?
[08:58:47] <anewton> andy: who is doing this
[08:58:51] <anewton> marc: end consumer
[08:58:55] <anewton> brian: happens at boot time
[09:00:37] <anewton> roger: soliciting a requirement
[09:01:05] <anewton> brian: protocol must have a mechanism to return a uri that can be used to report a suspected error in the mapping database
[09:01:51] <anewton> nadine: location section or mapping section:
[09:02:12] <anewton> brian: in place where answer is being returned
[09:02:20] <anewton> nadine: in validation request?
[09:02:38] <anewton> brian: most useful time to do it, but don't really care
[09:03:01] <anewton> ted: must provide a list of URI schemes in the protocol specification
[09:03:38] <anewton> brian: other thing, who can control the information in the database
[09:03:54] <anewton> hannes: there are requirements
[09:04:01] <anewton> tom: there are requirements in the security doc
[09:04:19] <anewton> brian: as long as the protocol controls it, that is ok
[09:04:25] <anewton> nadine: that works
[09:05:30] <anewton> andy: we are not writing the provisioning protocl
[09:05:35] <anewton> brian: you are right
[09:06:13] <anewton> roger: leave ma9 the way it is, add new req re brian's requst
[09:07:01] <anewton> hannes: security doc has requirements, but they are not mapping protocol documents
[09:07:14] <anewton> roger: issue 24
[09:09:04] <anewton> andy: why is last sentence needed
[09:09:10] <anewton> brian: pidf requires it
[09:09:45] <anewton> jon: work to rectifiy sip identity with rfc 3533
[09:10:13] <anewton> jon: pidf-lo identity doesn't have to be sip uri
[09:10:37] <anewton> brian: location needs to be signed, need some protections over forgery
[09:11:15] <anewton> jon: pidf-lo no compatible with presense data model
[09:11:30] <anewton> jon: pidf-lo does not think about device, etc in the same way
[09:13:59] <anewton> brian & jon talk about stuff with signed pidf-lo and how that gets passed to the mapping server with stripping out the identity
[09:15:09] <anewton> marc: why the mapping function cares about the source of the data
[09:15:21] <anewton> jon: identity not source
[09:16:12] <anewton> henning: the notion of signed data across that interface seems counter productive... this is different than conveyance to the PSAP
[09:16:52] <anewton> henning: useful to make the distinction that signed data for the mapping data to the mapping protocols
[09:17:06] <anewton> brian: we should allow for sending the identity
[09:18:10] <anewton> marc discusses the origns of this requirement
[09:18:37] <anewton> jon: James W. envisions are no identity being given to the mapping function
[09:20:41] <hardie> The mapping function must not require the true identity of the target for which the location information is attributed. Ideally, no identity information is provided to the mapping function. Where identity information is provided, it may be in the form of an unlinked pseudonym as defined in RFC 3963.
[09:22:28] <anewton> andy: it is just as easy to only paste the <location> as the pidf-lo
[09:23:20] <anewton> henning: we need to understand the requirement with regards to proposals
[09:23:33] <anewton> brian: the mapping function does not have to dereference.
[09:23:54] <anewton> tom: matter of trust relationships...
[09:27:35] <anewton> hannes: the text does not address the underlying question of sending signed data to the mapping function
[09:27:52] <anewton> henning: does anybody think there is a security benefit to do that>?
[09:28:56] <anewton> jon: only rational for sending signed data is for by reference
[09:33:31] <anewton> jon: in a dereference model the mapping function doesn't need the identity but may acquire the identity in the dereference action
[09:34:21] <anewton> henning: we need to be sure the protocol requirement for mapping does not require that we must pass the identity by value.
[09:34:36] <anewton> andy: agrees
[09:35:40] <anewton> henning: the non-requirement, the mapping protocol is not required to support the ability to dereference location references.
[09:36:01] <anewton> ted: we should not yellow flag for doing that.
[09:36:52] <anewton> andy: isn't that opposite of what marc asked for
[09:37:35] <anewton> marc: there are people who say that mapping functions will always have dereference rights
[09:37:57] <anewton> marc: that is unreasonable to require in the rulemaking
[09:38:48] <anewton> nadine: but the dereference host knows that it is an emergency mapping function.
[09:38:52] <anewton> andy: opens other issues
[09:39:09] <anewton> jon: end users will not understand this, but the CSP would
[09:39:37] <anewton> jon: don't see a lot of rational for passing uris to the mapping functions, but we should not rule it out
[09:40:27] <anewton> marc: but this must be remembered by small operators
[09:40:41] <anewton> ted: but you can still pass by value
[09:41:10] <anewton> hennging: the protocol must support the delivery of location information by value and may support dereferencing of location references
[09:41:51] <anewton> marc: the mapping server is in the rule set, what about lazy proxies.
[09:42:15] <anewton> jon: what is the distinction between the proxy doing it and the mapping server.
[09:42:29] <anewton> marc: I have a contract with my CSP, and there is a relationship there.
[09:42:46] <anewton> nadine: legal obligation for mapping servers to do this
[09:47:02] <anewton> jon: by value is the same as by reference with no authorization
[09:47:30] <anewton> hannes: by value can be seen by anybody on the path just as the uri being queried from anywhere
[09:49:21] <anewton> nadine: motivation for by reference is for extensibility in wireless environments
[09:51:33] <anewton> andy: concerned that other players can impersonate mapping servers
[09:51:57] <anewton> henning: we need to determine if this should or should not be supported
[09:52:22] <anewton> ted: but marc wants a MUST NOT, not you can do this but we don't care
[09:53:44] <anewton> room consensus: if the protocol does do by reference then that is fine, but it is out of scope of our work
[09:54:36] <hardie> "location by reference is not one of the evaluation criteria"
[09:56:46] <anewton> Ma21x being appended to Ma22x.
[09:56:49] <anewton> bio break!!!!!!
[10:17:52] <anewton> we're back
[10:18:04] <anewton> roger: issue 24 resolved
[10:19:05] <anewton> roger: on issue 26
[10:19:40] <anewton> brian: home and visited is missing...
[10:19:47] <anewton> hannes: number to dialstring
[10:19:51] <anewton> brian yes.
[10:20:24] <anewton> barbara: mechanism to distinquish between the two
[10:20:32] <anewton> brian: mechanism or mechanims
[10:20:42] <anewton> roger: where in the doc
[10:20:51] <anewton> brian: under universal identifier
[10:21:19] <anewton> btw, spencer is also scribing
[10:22:12] <anewton> ted: what about Id6?
[10:22:26] <anewton> ted: Id6 is about dialstrings not other identifiers?
[10:25:18] <anewton> discussion in the room if ID6 is about service types vs. dialstrings.
[10:26:18] <anewton> brian: advantage of IANA is that is up to local choice
[10:27:10] <anewton> henning: may discover that a particular service is not supported
[10:27:29] <anewton> brian: need to split up dialstrings from service identifieres
[10:29:18] <anewton> andy: are we in agreement that the requirements for dialstrings are different from service type requriemetns
[10:29:20] <anewton> room: yes
[10:29:46] <anewton> somewhere in there hannes explained the dialstring stuff
[10:30:10] <anewton> brian: we are changing the term "emergency identifier" to "emergency dialstring"
[10:30:52] <anewton> text on the screen re "visited" and "home" dialstrings.
[10:33:24] <anewton> henning: this needs to be clear that this is a mapping function requirement
[10:33:37] <anewton> andy: it isn't abundantly clear in the document
[10:34:24] <anewton> brian: requests roger to look at requirements that are for the mapping protocol and which are not
[10:37:35] <anewton> the room finds consensus that order of preference in collisions between visited emergency dialstrings and dialplans is a bcp issue and not to be in the requirements doc
[10:38:56] <anewton> brian: is it enough to say that service typs must be extensible
[10:39:24] <anewton> spencer: need to talk about happens when somebody requests a service that is not availalbe.
[10:39:31] <anewton> brian: yes
[10:40:22] <anewton> "lists of of emergency service types MUST be extensible and it is not necessary for every mapping to provide service for every service type."
[10:43:44] <anewton> discussion about extensiblity, brian basically says he is thinking of an IANA registry but the use of other identifiers can be used. Henning noted that absent protocol police there is nothing we can do anything anyway.
[10:45:41] <anewton> discussion about a univeral dialstring. brian points out that there is no way to enforce that.
[10:46:54] <anewton> roger: should we say there is no universal dialstring?
[10:47:27] <anewton> brian: I think everybody is saying there is no emergency universal dialstring, just a universal uri.
[10:48:19] <anewton> also discussion about mapping for particular service types. again, either the mapping service supports a particular service type or not, but that is not for us to enforce
[10:51:08] <anabolism> I can't hear whomever is speaking
[10:52:18] <anewton> resolution to issue 30 has been discussed
[10:52:55] <anewton> roger reading issue 25
[10:53:14] <anewton> room seems to think it is a reasonable requirement
[10:53:44] <anewton> nadine: question about clarification of the uri
[10:54:04] <anewton> henning: we need to clarify if this is the psap uri
[10:55:13] <anewton> henning: do we have a term other than "psap uri" to say "this is what you contact for the emergency".
[10:55:48] <anewton> henning: we define PSAP uri.
[10:55:50] <anewton> room agrees
[10:56:32] --- hardie has left
[10:56:43] <anewton> lunch time
[10:56:55] <anabolism> How long?
[11:56:58] <anewton> we are back
[11:58:09] <anewton> nadine: what about pre-emegency call
[11:58:19] <anewton> nadine: test calls
[11:58:39] <anewton> henning: doesn't matter because the mapping protocol is a separate function
[12:01:51] <anewton> henning: the question is if we want to say we want test calls.
[12:02:38] <anewton> roger: ma12 relevant?
[12:02:45] <anewton> andy: isn't it redundant
[12:02:53] <anewton> roger: move to strike it
[12:07:48] --- hardie has become available
[12:08:24] <anewton> discussion about test calls being in scope. Jon thinks it is not and perhaps the working group should do the things it is already chartered to do.
[12:16:27] <anewton> Jon and Brian discuss what protocol bits are required to do a test. Brian says that it is mostly having a .test URI.
[12:18:06] <anewton> Roger talks about doing call marking for testing.
[12:22:25] <anewton> henning: we have a tendency to take simple things and make them look complicated
[12:22:36] <anewton> hannes: I thought this was related.
[12:23:46] <anewton> randy: while a test that is successful now does not mean it will be sucessful in 10 minutes, the chances are that an unsuccessful test now will still be unsuccessful in 10 minutes.
[12:24:10] <anabolism> ...and so gives a chance to debug the problem
[12:26:29] <anewton> hannes: get things done that need to get done first. take out Ma12.
[12:27:00] <anewton> roger: what about issue25? add it to requirements document
[12:28:49] <anabolism> Is anyone speaking?
[12:31:34] <anewton> James thinks this is covered by pre-call routing and fallback URIs.
[12:32:09] <anewton> Issue 9 is resolved by deleting it.
[12:34:58] <anewton> Issue 10
[12:44:42] --- Shida has become available
[12:45:15] <anewton> After discussion, there is an issue with aliasing in the mapping database and issue with forcing database modifications just to work with ecrit.
[12:46:03] <anewton> Roger has text for Re9x on "No Modification of Location Databases"
[12:46:57] <anewton> In the case of databases containing civic addresses within location infromation servers, these dtabases may be used for multiple purposes and multiple applications (in addition to emergency service mapping).l The mapping protocol SHOULD NOT...
[12:47:10] <anewton> roger: issue 8
[12:47:13] <anewton> andy: resolved
[12:47:47] <anewton> roger: issue 14
[12:49:44] <hardie> shida are you local or listening to the bridge?
[12:53:44] --- jon-ietf has become available
[12:56:51] <Shida> Hi ted, I am joining only via Jabber.
[12:57:08] <hardie> there is a bridge, if you need to listen.
[12:57:12] --- HannesTschofenig has become available
[12:57:27] <Shida> I do realize that.. Thanks.
[12:57:27] <jon-ietf> listening is fun
[12:57:44] <HannesTschofenig> Please find the slides at http://www.ietf-ecrit.org/Interim2006/
[12:57:49] <anewton> No on hennings ID on ID
[12:58:06] <anewton> James, is the To field "911" or a URN.
[12:58:12] <anewton> Henning: no
[12:59:08] <anewton> Brian: may be the case that the first hop proxy cannot do the mapping.
[13:06:06] <anewton> Brian discusses algorithm with multiple tries through the proxy with 425. Only accept it from the first hop proxy.
[13:09:30] <anewton> barbara: it is reasonable to think that any device that knows its location for this purpose, then it knows about the emergency urn.
[13:09:58] <anewton> brian: what about "home" dialstring problem.
[13:15:42] <anewton> discussion regarding using 425 to trick somebody into handing over LI vs. using 425 in tricking into making an emergency phone call.
[13:40:28] <anewton> after long, long discussion on the 425 solution, the room is coming to the conclusion that it is trying to solve a corner case and the real solution is so heavy weight that it is not desirable just to support a corner case.
[13:55:46] <anewton> short break!
[14:02:51] --- spencerdawkins has become available
[14:09:58] --- Dan Mongrain has become available
[14:18:53] <anewton> we are back
[14:19:54] <anewton> henning is showing a slide about the options for doing the sos id
[14:20:46] <HannesTschofenig> henning shows slide 4 of http://www.ietf-ecrit.org/IETF64/IETF64-ECRIT-Emergency-Service-Identifiers.ppt
[14:21:40] <anewton> though the slide has "5" on it
[14:21:58] <HannesTschofenig> correct. slide 5
[14:24:48] <anewton> henning wants to know if we should do both sos@ and sos URN.
[14:24:52] <anewton> brian: no
[14:24:56] <anewton> andy: agree with brian
[14:28:01] <anewton> ted: do not confuse the URN with service: scheme
[14:28:16] <anewton> room decides to proceed with URN
[14:29:02] <Shida> Hum on accepting it..
[14:29:32] <anewton> question on adding it as a working group item.
[14:29:36] <anewton> big hum in favor
[14:29:55] <anewton> confusion with phone participants thinking the hum was for dropping the document
[14:38:41] <anewton> now discussing Henning architecture considerations document
[14:38:49] <HannesTschofenig> we are now looking at the http://www.ietf-ecrit.org/Interim2006/ecrit-lump.ppt
[14:38:53] <HannesTschofenig> slide 4
[14:53:24] --- hardie has left: Replaced by new connection
[14:57:36] --- Dan Mongrain has left: Disconnected
[15:16:36] --- Shida has left
[15:20:32] <anewton> moving off ot that presentation to security threats and reqs
[15:25:45] --- hardie has become available
[15:26:47] <hardie> we are looking at draft-taylor-ecrit-security-threats-01.txt
[15:31:26] <anewton> long discussion on security threats for non SIP protocols.
[15:41:02] <HannesTschofenig> The text below figure 1 needs to indicate that this is an ideal call.
[15:41:26] <anewton> the concern was that MUST acquire location for making a call is not correct.
[15:41:37] <HannesTschofenig> the note at bullet (3) below figure 1 will be removed./
[15:51:02] --- hardie has left: Replaced by new connection
[15:53:34] <HannesTschofenig> longer discussion about the scope of the security document.
[15:59:50] <anewton> tom brings up a use case where an end device (phone) marks a call as an emergency to get a free call.
[16:13:34] --- anabolism has left
[16:13:59] --- anabolism has become available
[17:12:55] <HannesTschofenig> we basically decided that the document will be rewritten with a focus on the mapping protocol and on the emergency identifier.
[17:17:43] --- anewton has left
[17:18:56] --- jon-ietf has left
[17:30:42] --- spencerdawkins has left: Disconnected
[17:44:42] --- HannesTschofenig has left: Disconnected
[19:20:11] --- anabolism has left
[19:43:54] --- spencerdawkins has become available
[22:17:30] --- spencerdawkins has left: Replaced by new connection