Subject: [Ecrit] Usage of service URN by enterprises (RFC 5031)

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 15 Apr 2008 15:28:19 +0200

RFC 5031 defines service URN as:

   urn:service:sos  The generic 'sos' service reaches a public safety
      answering point (PSAP), which in turn dispatches aid appropriate
      to the emergency.  It encompasses all of the services listed
      below.

The definition of PSAP from RFC 5012 is as follows:

   Public Safety Answering Point (PSAP):  A PSAP is a facility where
      emergency calls are received under the responsibility of a public
      authority.  (This terminology is used by both the European
      Telecommunications Standards Institute (ETSI), in ETSI SR 002 180,
      and the National Emergency Number Association (NENA).)  In the
      United Kingdom, PSAPs are called Operator Assistance Centres; in
      New Zealand, Communications Centres.  Within this document, it is
      assumed, unless stated otherwise, that PSAPs support the receipt
      of emergency calls over IP, using appropriate application layer
      protocols, such as SIP for call signaling and RTP for media.

If I have an enterprise, that provides its own emergency services, with
its own emergency service routeing proxy and its own answer points, is
it appropriate or inappropriate to use urn:service:sos. If it is
inappropriate, is there a service urn that should be used? Otherwise it
would seem that we are back to using numbers. 

While many enterprises will use the public network capability to respond
to an emergency, there are cases where it is inappropriate, or indeed
impossible for the the public network capability to provide an
appropriate response for an enterprise.

Regards

Keith
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Apr 2008 10:26:27 -0400

We may have inadvertently created a problem.

The intention is to allow the enterprise to operate the PSAP, and
urn:service:sos to be used to return the URI of that enterprise PSAP.

This clearly occurs in specific instances.

Does 5031 reference the definition in 5012?  If so, we may need an erratum.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DRAGE, Keith (Keith)
Sent: Tuesday, April 15, 2008 9:28 AM
To: ECRIT
Subject: [Ecrit] Usage of service URN by enterprises (RFC 5031)

Regards

Keith

---

From: Richard Barnes <[email-masked]>
Date: Tue, 15 Apr 2008 11:01:32 -0400

Actually, I think this use case might introduce more problems than the 
one Keith pointed out.  For instance, consider the case where
1) The endpoint/caller is connected to an access net with its own PSAP
2) The endpoint/caller does his own LoST routing.

ISTM that for the caller to end up with the enterprise PSAP's URI within 
the current framework, one of a three things has to happen:

1) Forced private LoST: The caller uses a LoST resolver operated by the 
access network, so that the resolver can direct the caller to the 
enterprise PSAP.  While the LoST discovery mechanism enable this to 
happen, there is not a requirement in framework/phonebcp for the caller 
to prefer the local LoST resolver (at least I haven't found one).

2) Private LoST in the public tree: If the caller is allowed to use the 
public LoST infrastructure, then these private arrangements must be 
accounted for in that infrastructure.
2a) To do this without changing LoST routing, you would have to map 
specific geographic areas to enterprise PSAPs, so that a standard LoST 
query would route to the enterprise LoST server.
2b) If we're willing to change the LoST routing, then caller could 
include a tag in the request (in the URN or otherwise) that indicates 
the network to which the requestor is connected, so that queries could 
be routed based on the tag.  Or the LoST server could route based on the 
IP address of the caller.

The problem is even harder when a proxy does LoST routing on behalf of 
an endpoint.  Solutions engineering aside, do people think this is 
actually a problem?

--Richard

P.S.: Among these options, my preference is actually for option 2b. 
Option 1 encourages different resolvers to present different views of 
the LoST infrastructure.  Option 2a is probably incompatible with 
devices that have imprecise location (given that the "enterprise 
regions" will usually be small).  Option 2b cleanly, explicitly 
incorporates additional routing parameters (i.e., not location or 
service) into LoST.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Apr 2008 09:31:49 -0700

>would seem that we are back to using numbers.

Hi Keith,
	Are these enterprise PSAPs recognized by/coordinated with
the local government so that the services they provide are the same
as those in the local jurisdiction?  If so, then I think them re-using the
urn:service:sos is fine.  But if not, then I think a different urn is required.
There is already a difference between dialing 911 and 9-911 in many
enterprises (do I want the local security, or does someone need an
ambulance?), and continuing to distinguish between the two seems
required. 

>appropriate response for an enterprise.

	The examples I can come up with where it is impossible are
all basically military reservation examples.  Those folks tend to find
lots of places where they coordinate with local authorities, so coordinating
this does not seem to be a huge additional burden.  What private
enterprise cases are there where it is impossible?

				regards,
					Ted

---

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Apr 2008 09:46:00 -0700

>the current framework, one of a three things has to happen:

First, are we sure that's the goal?  It seems to me that the goal is to
make sure that the appropriate emergency services actually reach
the caller.  If I connect to example.com's access network but
use a VSP infrastructure instead of the enterprise PBX, I might
end up calling the "covering" PSAP of the town, county, or other
jurisdiction, rather than getting the enterprise PSAP.  If the covering
PSAP and the enterprise are going to contact the same emergency
service responders, then the difference is really only extra load
on the covering PSAP.   In my opinion, that's an acceptable result
and appropriate to the VSP/enterprise access vs. PBX/enterprise
network topology difference.

If there are different emergency service responders, but the covering PSAP
dispatches emergency service responders that can and do reach the emergency,
 then we might have lost time and used resources but basically, the right thing
still happens.   There's a potentially important optimization here, in other words,
but no need to re-think the architecture.(1)  If the covering PSAP would
dispatch resources that are *not permitted* to serve the area where
the call came from (and here we've shifted into corner cases like
the military base call going off--base), then it seems to me there
has to be a mechanism to delineate those areas *and coordinate
the coverage areas*.  In other words,  the covering PSAP would have
to have a way to forward to the "local" PSAP  so that it could dispatch
the permitted resources.  That requires some real coordination.

As I said in my response to Keith, there may well need to be a different
URN for "local" non-jurisidictional emergency response (the difference
between 911 and 9-911 in many enterprises in the U.S. now).  But
we should not, in my opinion, ever prevent someone from reach the
jurisdictional response because of the presence of a local response.
In the military reservation case, that means the covering area has to
have a carve-out for the military reservation, but that seems to me
pretty much the expected behavior.  Once the carve-out is present,
the standard LoST mechanisms will get you the right PSAP (or,
in the worst case, you get forwarded from the initial call taker).

			regards,
				Ted

(1) And that potential optimization needs to focus, at least in my opinion,
on letting the access network user/device know that it can use access network
resource to determine the routing to PSAPs; once the access network resources
are used, the local PSAP is in the mapping database and its URIs can be returned
with no architectural change. 
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Apr 2008 13:53:41 -0400

I'm not sure what "private LoST routing" means.  I'm guessing that, say, a
campus provides a LoST server with different answers from the public
network.  This is analogous today to calling on a wireline vs a wireless
phone on campus.

Where I could see an issue is LoST provided by the access network and LoST
provided by the calling network.

Generally, I think all LoST contents should be alike.
I think it's preferable for the access network to provide the pointer to the
LoST service.  If there is some local routing issue, it's the access network
that has the best information.

Brian

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, April 15, 2008 11:02 AM
To: Brian Rosen
Cc: 'DRAGE, Keith (Keith)'; 'ECRIT'
Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031)

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 15 Apr 2008 14:34:05 -0400

> that has the best information.

Is that a requirement that should be added into phonebcp/framework?  E.g.,

"
ED-* When an endpoint has obtained a LoST server via an discovery 
mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer the 
discovered LoST server over LoST servers configured by other means. 
That is, the endpoint SHOULD send queries to this LoST server, using 
other LoST servers only if these queries fail.
"

--RB

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Apr 2008 21:42:34 +0300

For the emergency services use case that makes a lot of sense.

Ciao
Hannes

Richard Barnes wrote:
>>> Does 5031 reference the definition in 5012?  If so, we may need an
>>>       
>> erratum.
>>     
>>> Brian
>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 16 Apr 2008 21:40:43 -0400

Standard beef: A requirement with lots of SHOULD is useless.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 16 Apr 2008 22:30:32 -0400

I'm fine with making it a MUST; I don't see any obvious problems that 
that would cause.

On the other hand, I'm not entirely convinced that it's necessary for an 
endpoint to behave in that way in order for it to work interoperably. 
Like Brian says, "all LoST contents should be alike"; a query to any 
resolver (discovered or otherwise) should return the same result.  In 
practice, that won't be true (particularly when deployment is patchy), 
so it's preferable to use the local resolver.  The "SHOULD" in this case 
would be "SHOULD, unless otherwise configured" (just like with DNS 
servers today).

So either SHOULD or MUST is ok with me.  I'm feeling agreeable today...

--RB

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Apr 2008 17:10:30 +0300

The problem here is again LoST usage for emergency services and LoST 
usage for other services.
For the emergency services context I would put a MUST instead of the 
SHOULD.
For a pizza service I would even put a MAY in there.

Brian, are you happy to put an adjusted version of Richard's proposal + 
Henning's improvements into the document?

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 29 Apr 2008 10:32:09 -0400

Yes, but we need to agree on MUST/SHOULD.  -phonebcp is emergency service
specific, so anything we say there is for the emergency service context.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Tuesday, April 29, 2008 10:11 AM
To: Henning Schulzrinne
Cc: 'ECRIT'
Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031)

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Apr 2008 17:37:29 +0300

What about the following proposal:

ED-* When an endpoint has obtained a LoST server via the DHCP based discovery mechanism [ref] then it MUST prefer the discovered LoST server over LoST servers configured via other mechanisms. That is, the endpoint MUST send queries to this LoST server first before contacting other LoST servers only if queries to the locally discovered LoST servers fail. 

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Apr 2008 10:38:26 -0400

Unless we can formulate some reason, in general, as to why this  
behavior should differ, I'd go for MUST. In really special  
circumstances, implementors could presumably not use DHCP (or DNS) at  
all.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Apr 2008 17:40:57 +0300

If developers cannot use DHCP for some reason or DHCP does not return 
any LoST servers then one has to fallback to other mechanisms, such as 
manual configuration or DNS.

Btw, we do not provide a way to discover local LoST servers using DNS 
without also using the DHCP discovery mechanism.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Apr 2008 10:42:42 -0400

Sounds ok to me. I think this can be shortened:

If an endpoint has discovered a LoST server via DHCP [ref], it MUST  
query that LoST server first. The end point only queries other LoST  
servers, such as those configured manually, if that query failed.

On Apr 29, 2008, at 10:37 AM, Hannes Tschofenig wrote:

> ED-* When an endpoint has obtained a LoST server via the DHCP based  
> discovery mechanism [ref] then it MUST prefer the discovered LoST  
> server over LoST servers configured via other mechanisms. That is,  
> the endpoint MUST send queries to this LoST server first before  
> contacting other LoST servers only if queries to the locally  
> discovered LoST servers fail.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Apr 2008 12:30:59 -0400

I second the MUST, given that these documents are emergency-specific. 
(E.g., it would not be appropriate in LoST itself.)

--RB

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 29 Apr 2008 14:33:20 -0400

I've been thinking about this wording, and I think it needs one
additional clause. It needs to be clear that this only applies to
queries for sos urns. Although phonebcp is supposed to only be about
emergency services, the requirement, as worded, could be misconstrued to
apply to all service urns.

I could easily imagine that a VSP has the phones they provide to their
users configured to always query the VSP LoST server for the closest
something-or-other. I'd rather not use language that could be
interpreted as preventing this from happening.

Maybe:
If an endpoint has discovered a LoST server via DHCP [ref], it MUST  
query that LoST server first. The end point only queries other LoST  
servers, such as those configured manually, if that query failed. This
requirement only applies to queries relating to emergency services, and
not the use of LoST for other services.

Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Barnes
Sent: Tuesday, April 29, 2008 12:31 PM
To: Henning Schulzrinne
Cc: 'ECRIT'
Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031)

--RB

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Apr 2008 15:20:36 -0400

> interpreted as preventing this from happening.

Just to be clear, are you including emergency services in 
"something-or-other"?  Because I think the gist of this requirement is 
that when the phone is looking for emergency service, it's not okay for 
it to always go to the VSP.  This all seems consistent with your text below.

 > not the use of LoST for other services.

That text looks fine to me.

--RB

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 29 Apr 2008 15:27:48 -0400

No, I was specifically not including emergency services in
"something-or-other". 
Barbara

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, April 29, 2008 3:21 PM
To: Stark, Barbara
Cc: Henning Schulzrinne; ECRIT
Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031)

Just to be clear, are you including emergency services in 
"something-or-other"?  Because I think the gist of this requirement is 
that when the phone is looking for emergency service, it's not okay for 
it to always go to the VSP.  This all seems consistent with your text
below.

 > servers, such as those configured manually, if that query failed.
This

--RB

> The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential, proprietary,
and/or privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon this information
by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the
material from all computers. GA622

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 29 Apr 2008 16:26:06 -0400

Just popping in here with an editorial suggestion...

> That text looks fine to me.

The text looks fine to me technically, but it seems to "hide" the point - 
"MUST query LoST server discovered via DHCP first for all queries relating 
to emergency services", if I'm understanding this thread. I'd suggest 
inverting as

If an endpoint has discovered a LoST server via DHCP [ref], it MUST query 
that LoST server first, for all queries relating to emergency services. The 
endpoint only queries other LoST servers, such as those configured manually, 
if that query fails.

<new paragraph>

This requirement does not apply to the use of LoST for non-emergency 
services.

Thanks,

Spencer