Subject: [Ecrit] New work in ECRIT

From: Marc Linsner <[email-masked]>
Date: Tue, 03 Aug 2010 09:19:50 -0400

During the meeting last week the following drafts were discussed in the
context of accepting them as WG items.

draft-rosen-ecrit-additional-data
draft-schulzrinne-ecrit-psap-callback
draft-schulzrinne-ecrit-unauthenticated-access
draft-tschofenig-ecrit-trustworthy-location
draft-rosen-ecrit-data-only-ea

The chairs and ADs have reviewed the level of interest in these, compared
the work to the current charter and believe these fit within the scope of
ECRIT.

We asked during the meeting if anyone objects to accepting any or all of
these drafts as WG items.  So, now, we're asking on the list.

If you object to any of these drafts becoming WG items, please explain if
you think the work is something ECRIT should not do, or if you simply have
problems with current version of the particular draft.  No response is a
show of support for all of this work.

Once the above question is answered, the chairs will devise a work plan to
finish the accepted work.

Also discussed in the meeting was the priority order of getting these drafts
completed, and it was the general feeling that psap-callback,
unauthenticated-access, and trustworthy-location were the most difficult and
would take more time.  Of those three the general feeling was the
psap-callback was the highest priority.  If you have an opinion on which
draft should completed first, please send it to the list.

Please respond by COB on Wednesday, 8/11/2010 if you have objections to any
of this work, or you have strong feelings on the priority of the work.

Thanks,

-Marc, Richard, Roger-

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Aug 2010 10:25:44 -0700

My humble suggestion is that draft-rosen-ecrit-additional-data is both straightforward and highly beneficial.  While IETF tradition would suggest that items with such a high benefit/cost ratio should be delayed indefinitely or abandoned in favor of items that are more intractable,  I'd suggest a concession to common sense in this isolated instance.

Of course, in order to ensure that the WG does not debase itself in an orgy of productivity, tradition requires that the WG take on a number of work items which are "hard" only because the wrong questions are being asked.   I'd assert that both Unauthenticated Access and PSAP callback  fall in this category.    

Unauthenticated Access is "hard" because it represents a solution without a real problem.  There is no regulatory requirement for this today, nor is there likely to be one in the near future because the "solution" would itself be a problem and because technology such as femtocells will make the "problem" disappear in due course.

PSAP Callback is "hard" largely because of the disconnect between the PSTN way of thinking and the reality of VOIP, which will result in extended (and largely fruitless) "discussions", until the passage of the leaves the obvious solution in plain view, like a whale washed up on the beach.  Serializing other work items until this "hard" problem is "solved" will essentially cause them to wait in the queue until our teeth are but a memory. 

> Date: Tue, 3 Aug 2010 09:19:50 -0400
> From: [email-masked]
> To: [email-masked]
> Subject: [Ecrit] New work in ECRIT
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 3 Aug 2010 21:12:58 +0200

Bernard, 

could you clarify your comment regarding the relation of femtocells to
the unauthenticated draft? It is correct that some femtocell
configurations are considered an issue for emergency access, but I am
not sure which relation to unauthenticated you are pointing at.

Thanks,

Dirk

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Bernard Aboba
Sent: Tuesday, August 03, 2010 7:26 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ecrit] New work in ECRIT

My humble suggestion is that draft-rosen-ecrit-additional-data is both
straightforward and highly beneficial.  While IETF tradition would
suggest that items with such a high benefit/cost ratio should be delayed
indefinitely or abandoned in favor of items that are more intractable,
I'd suggest a concession to common sense in this isolated instance.

Of course, in order to ensure that the WG does not debase itself in an
orgy of productivity, tradition requires that the WG take on a number of
work items which are "hard" only because the wrong questions are being
asked.   I'd assert that both Unauthenticated Access and PSAP callback
fall in this category.   

Unauthenticated Access is "hard" because it represents a solution
without a real problem.  There is no regulatory requirement for this
today, nor is there likely to be one in the near future because the
"solution" would itself be a problem and because technology such as
femtocells will make the "problem" disappear in due course.

PSAP Callback is "hard" largely because of the disconnect between the
PSTN way of thinking and the reality of VOIP, which will result in
extended (and largely fruitless) "discussions", until the passage of the
leaves the obvious solution in plain view, like a whale washed up on the
beach.  Serializing other work items until this "hard" problem is
"solved" will essentially cause them to wait in the queue until our
teeth are but a memory.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Aug 2010 14:20:22 -0700

With femtocells, emergency calls (including non-service initialized  
ones) can be made indoors, without the handset having to obtain access  
to a corporate or hotspot network.  As a result, a company could  
forego the challenge, expense and liability associated with  
engineering unauthenticated emergency calling for non-employees.

On Aug 3, 2010, at 12:12 PM, "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked] 
 > wrote:

> Bernard,
>
>
>
> could you clarify your comment regarding the relation of femtocells  
> to the unauthenticated draft? It is correct that some femtocell  
> configurations are considered an issue for emergency access, but I  
> am not sure which relation to unauthenticated you are pointing at.
>
>
>
> Thanks,
>
> Dirk
>
>
>
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of ext Bernard Aboba
> My humble suggestion is that draft-rosen-ecrit-additional-data is  
> both straightforward and highly beneficial.  While IETF tradition  
> would suggest that items with such a high benefit/cost ratio should  
> be delayed indefinitely or abandoned in favor of items that are more  
> intractable,  I'd suggest a concession to common sense in this  
> isolated instance.
>
> Of course, in order to ensure that the WG does not debase itself in  
> an orgy of productivity, tradition requires that the WG take on a  
> number of work items which are "hard" only because the wrong  
> questions are being asked.   I'd assert that both Unauthenticated  
> Access and PSAP callback  fall in this category.
>
> PSAP Callback is "hard" largely because of the disconnect between  
> the PSTN way of thinking and the reality of VOIP, which will result  
> in extended (and largely fruitless) "discussions", until the passage  
> of the leaves the obvious solution in plain view, like a whale  
> washed up on the beach.  Serializing other work items until this  
> "hard" problem is "solved" will essentially cause them to wait in  
> the queue until our teeth are but a memory.
>
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 04 Aug 2010 14:13:26 -0500

>draft-rosen-ecrit-data-only-ea

Of the 5 items above, each have their advocates and uses (some more 
than others). That said, I believe the data-only-ea is imperative and 
am willing to work on it any way I can.

I believe we can't avoid doing the psap-callback item, as there are 
too many organizations that want something from us on this topic - or 
they will each do it their own way. If we can provide a basis or a 
complete solution for others to use, we should do this too.

James

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 5 Aug 2010 09:04:07 +0300

Hi Marc, 

I believe all of them are important but their timeline is quite
different. 

I expect the draft-rosen-ecrit-additional-data to be finished first
since it builds on top of existing work from NENA. What is missing at
the moment is the security and privacy writeup. 

draft-rosen-ecrit-data-only-ea is also a fairly easy document and it
again builds on top of the NENA i3 work. What is left is to align the
approach of dealing with location with the NENA i3 specification (or at
least check whether they say the same). 

draft-tschofenig-ecrit-trustworthy-location does not require a protocol
definition; instead the challenge is to present the problem in a clear
way and to come to an agreement of the suggestions. I believe that this
will take a bit more time. 

Then, there are 2 hard problems: draft-schulzrinne-ecrit-psap-callback,
and draft-schulzrinne-ecrit-unauthenticated-access (whereby the latter
is even harder, I believe). From a milestone point of view I would put
them last. draft-schulzrinne-ecrit-unauthenticated-access is quite
useful and overlaps a bit with ECRIT Direct (i.e. the draft that
provides a writeup about the case where there is no VSP/ASP in the
signaling exchange). 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Marc Linsner
> Sent: Tuesday, August 03, 2010 4:20 PM
> To: 'ecrit'

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 5 Aug 2010 09:21:36 +0300

Hi Bernard, 

a few comments to your statements below: 

________________________________

	Sent: Tuesday, August 03, 2010 8:26 PM

	My humble suggestion is that draft-rosen-ecrit-additional-data
is both straightforward and highly beneficial.  While IETF tradition
would suggest that items with such a high benefit/cost ratio should be
delayed indefinitely or abandoned in favor of items that are more
intractable,  I'd suggest a concession to common sense in this isolated
instance.
	
	Of course, in order to ensure that the WG does not debase itself
in an orgy of productivity, tradition requires that the WG take on a
number of work items which are "hard" only because the wrong questions
are being asked.   I'd assert that both Unauthenticated Access and PSAP
callback  fall in this category.   
	
	Unauthenticated Access is "hard" because it represents a
solution without a real problem.  There is no regulatory requirement for
this today, nor is there likely to be one in the near future because the
"solution" would itself be a problem and because technology such as
femtocells will make the "problem" disappear in due course. 
	 
	I have to disagree with you and here are my arguments.  The
document covers a number of scenarios, even though we always just
short-cut the description and talk about "unauthenticated access":
	 a) No access authorization 
	 b) No ASP  
	 c) Zero-balance ASP 
	 
	There are differences between the legacy telephony system and
VoIP. No doubt. We do, however, see people moving towards IP-based
networks and now the question is how the existing regulatory
requirements will apply to an IP-based environment. With all the years
we have had a hard time to figure out how this is going to work out
particularly since there is no flag day. Regulators, as you know, try to
claim that they are technology neutral and therefore they are likely
going to stick with their requirements and assume that technical people
will get the rest to work. Many people had looked at the requlatory
space and have not come up with a consistent answer of what all the
regulatory requirements for VoIP systems are (given that regulators are
often not too explicit). Maybe we should interact with NENA and EENA to
hear their view on the regulatory situation. 
	 
	Let me talk about the above three items in context of the legacy
infrastructure: 
	For (a) and (c) there are regulatory requirements. (b) is a case
that cannot happen in the legacy technology but is quite likely in the
VoIP case (see the more verbose description at
http://tools.ietf.org/html/draft-winterbottom-ecrit-direct-02). 
	 
	From a VoIP point of view I would be really surprised if (c) is
not useful in a VoIP context as well. As mentioned in the previous
paragraph, (b) might actually be desirable from a communication point of
view and I hear the argument about the applicable jurisdiction all the
time. (a) is clearly tough and maybe the only thing we can do in this
document is to point out some of the challenges and discourage it. With
the ESWs we have lots of presenters talking about this topic and we
tried to convince people that (a) is not a good approach but
nevertheless the feedback we got is that people from the regulatory side
still see some value in it.  I fear that just because we do not like it
does not make it go away. For the same reason the 3GPP has worked on
solutions for IMS in this space. 

	 In a nutshell, I believe that this document is very useful
already if it only provides a way to describe the differences between
the legacy technology and why certain concepts cannot be mapped 1-to-1.
Talking about the architectural challenges and what aspects need to be
considered will be useful for readers as well. There are simpler cases
that can be tackled, such as (b) and (c), with a somewhat detailed
description.
	 
	PSAP Callback is "hard" largely because of the disconnect
between the PSTN way of thinking and the reality of VOIP, which will
result in extended (and largely fruitless) "discussions", until the
passage of the leaves the obvious solution in plain view, like a whale
washed up on the beach.  Serializing other work items until this "hard"
problem is "solved" will essentially cause them to wait in the queue
until our teeth are but a memory.  
	 
	As we discussed during the IETF week I will interview some more
emergency services people about the user interface experience to gather
some more data about this aspect. 
	 
	Ciao
	Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 5 Aug 2010 16:50:14 +0800

Some thoughts for people to "kick around".

What's the equivalent of these scenarios in the PSTN world? Some examples:

 1.  A SIMless mobile phone is still able to initiate a circuit service session with the emergency call centre applicable to the location its calling from
 2.  A registered mobile phone with a zero pre-paid balance is still able to initiate a circuit service session with the applicable emergency call centre
 3.  A pay-phone can be used to initiate a circuit service session with the applicable emergency call centre without inserting any money
 4.  A residential POTS connection can still be used to initiate a circuit service session to the applicable emergency call centre even though there is no active line rental subscription

These are all real examples applicable in one or more combinations in one or more parts of the world.

With respect to broadband Internet connectivity, it is only necessary to substitute "circuit service session" with "IP packet session" and to consider the equivalent connectivity situations:

 1.  A SIMless device (wanting to be) connected to an LTE or WiMAX access (there is no circuit service available on these RANs)
 2.  An LTE or WIMAX device with a zero prepaid balance
 3.  A WiFi device connected to a "non-free" public hotspot
 4.  A residential DSL connection (connected to the DSLAM) that does not have an active subscription

The concepts are similar but the technical challenges associated with actually permitting the desired IP packet session to be established with the appropriate emergency call centre are profound and vary considerably with each technology. Some technical complication arises because layer 3 service has to be established before the ECRIT procedures even become applicable - so there's a catch-22.

Considerable amounts of detail with respect to how such "unauthenticated access" might be achieved are network technology specific and outside the scope of the IETF.

One consideration with respect to whether it's even worth the investment of human capital in "solving" this "problem" is that we live in a different world than the one that defined mid-twentieth century telephony (well - many of us do). We live in a world where access to the Internet is being tabled as a fundamental human right. Certainly it's the case that it's much easier to assume that people have connectivity than it ever used to be. Some jurisdictions have recently decided to disable SIMless calling to emergency services because its nuisance contribution far outweighed its value. Approximately zero emergency calls from SIMless devices were genuine; it's not the kind of world where people carry around an unregistered device just in case they need to make an emergency call.

So - we could put a lot of energy into trying to define the parameters of a concept that will never have a material regulatory basis.

Cheers,
Martin

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, 5 August 2010 4:22 PM
To: ext Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [Ecrit] New work in ECRIT

Hi Bernard,

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bernard Aboba

I have to disagree with you and here are my arguments.  The document covers a number of scenarios, even though we always just short-cut the description and talk about "unauthenticated access":
 a) No access authorization
 b) No ASP
 c) Zero-balance ASP

There are differences between the legacy telephony system and VoIP. No doubt. We do, however, see people moving towards IP-based networks and now the question is how the existing regulatory requirements will apply to an IP-based environment. With all the years we have had a hard time to figure out how this is going to work out particularly since there is no flag day. Regulators, as you know, try to claim that they are technology neutral and therefore they are likely going to stick with their requirements and assume that technical people will get the rest to work. Many people had looked at the requlatory space and have not come up with a consistent answer of what all the regulatory requirements for VoIP systems are (given that regulators are often not too explicit). Maybe we should interact with NENA and EENA to hear their view on the regulatory situation.

Let me talk about the above three items in context of the legacy infrastructure:
For (a) and (c) there are regulatory requirements. (b) is a case that cannot happen in the legacy technology but is quite likely in the VoIP case (see the more verbose description at http://tools.ietf.org/html/draft-winterbottom-ecrit-direct-02).

>From a VoIP point of view I would be really surprised if (c) is not useful in a VoIP context as well. As mentioned in the previous paragraph, (b) might actually be desirable from a communication point of view and I hear the argument about the applicable jurisdiction all the time. (a) is clearly tough and maybe the only thing we can do in this document is to point out some of the challenges and discourage it. With the ESWs we have lots of presenters talking about this topic and we tried to convince people that (a) is not a good approach but nevertheless the feedback we got is that people from the regulatory side still see some value in it.  I fear that just because we do not like it does not make it go away. For the same reason the 3GPP has worked on solutions for IMS in this space.

 In a nutshell, I believe that this document is very useful already if it only provides a way to describe the differences between the legacy technology and why certain concepts cannot be mapped 1-to-1. Talking about the architectural challenges and what aspects need to be considered will be useful for readers as well. There are simpler cases that can be tackled, such as (b) and (c), with a somewhat detailed description.

As we discussed during the IETF week I will interview some more emergency services people about the user interface experience to gather some more data about this aspect.

Ciao
Hannes

---

From: Ray Bellis <[email-masked]>
Date: Thu, 5 Aug 2010 09:43:24 +0000

On 5 Aug 2010, at 09:50, Dawson, Martin wrote:

> With respect to broadband Internet connectivity, it is only necessary to substitute “circuit service session” with “IP packet session” and to consider the equivalent connectivity situations:
>  
> 	• A SIMless device (wanting to be) connected to an LTE or WiMAX access (there is no circuit service available on these RANs)
> 	• An LTE or WIMAX device with a zero prepaid balance
> 	• A WiFi device connected to a “non-free” public hotspot
> 	• A residential DSL connection (connected to the DSLAM) that does not have an active subscription

The DSL example is (IMHO) incorrect - an inactive subscriber only has layer 2 (typically ATM) and does not have any IP connectivity.

Establishing layer 3 requires a PPP session with a complete IPCP handshake with the ISP.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 5 Aug 2010 18:00:40 +0800

I agree. That's my point. It is, nevertheless, the corresponding situation to a POTS line (connected to a line card in the local exchange) that doesn't have an active subscription. It used to be the case in Australia (may still be) that a TripleZero call still be able to be made on such a line. From an end user perspective, it's the same situation - two wires running between the house and the Telco. The technicalities, however, are different and DSL certainly wasn't implemented with this constraint in mind.

My suggestion is that it's not a worthwhile investment in effort to try and work out how these situations could still support access to the emergency service until such time as regulators insist it's a requirement. And given the technical complications and state connectedness of people generally, I think it would be unlikely that regulators would decide such impositions are necessary. The technicality at the moment is that any emergency call made over broadband Internet access (fixed,  untethered, or mobile) is, by definition, VoIP and so traditional service impositions don't apply. For operators to self-impose these requirements is creating a rod for their own backs - and taking on some very gnarly challenges for probably no good reason.

Cheers,
Martin
________________________________________
From: Ray Bellis [[email-masked]]
Sent: Thursday, 5 August 2010 7:43 PM
To: Dawson, Martin
Cc: Tschofenig, Hannes (NSN - FI/Espoo); ext Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [Ecrit] New work in ECRIT

Ray

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 6 Aug 2010 10:39:23 +0200

Are you saying the issue of how to get into a hotspot for emergency without credentials will go away because there will be Femtocells around anyway? Not sure this will be the general case soon.

However, there are also issues that apply to Femto access (not subscribed/prepaid empty/CSG configurations etc). The idea is not to limit considerations to one specific radio technology like WiFi.

Dirk

From: ext Bernard Aboba [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2010 11:20 PM
To: Kroeselberg, Dirk (NSN - DE/Munich)
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [Ecrit] New work in ECRIT

With femtocells, emergency calls (including non-service initialized ones) can be made indoors, without the handset having to obtain access to a corporate or hotspot network.  As a result, a company could forego the challenge, expense and liability associated with engineering unauthenticated emergency calling for non-employees. 

On Aug 3, 2010, at 12:12 PM, "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]> wrote:

	Bernard, 

	could you clarify your comment regarding the relation of femtocells to the unauthenticated draft? It is correct that some femtocell configurations are considered an issue for emergency access, but I am not sure which relation to unauthenticated you are pointing at.

	Thanks,

	Dirk

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 13 Aug 2010 15:51:13 -0400

Yeah, I'm as confused as Dirk here.  The IP network behind the  
femtocell would still have to have a way to provide unauthenticated  
emergency calling, just like any other IP network.  (I don't think  
it's possible to punt this to IMS emergency calling, since that only  
covers the case where the VoIP service being used is offered by the  
femtocell/IP-access provider.)

On Aug 6, 2010, at 4:39 AM, Kroeselberg, Dirk (NSN - DE/Munich) wrote:

> Are you saying the issue of how to get into a hotspot for emergency  
> without credentials will go away because there will be Femtocells  
> around anyway? Not sure this will be the general case soon.
> However, there are also issues that apply to Femto access (not  
> subscribed/prepaid empty/CSG configurations etc). The idea is not to  
> limit considerations to one specific radio technology like WiFi.
>
> Dirk
>
> ones) can be made indoors, without the handset having to obtain  
> access to a corporate or hotspot network.  As a result, a company  
> could forego the challenge, expense and liability associated with

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 13 Aug 2010 13:29:09 -0700

I was considering a scenario where a Femtocell provides access to an
existing carrier network inside the building, where signals might not
otherwise propagate.   So if a visitor had a cellular handset that could
make an emergency call, they could use that, regardless of whether they
could obtain access to an alternative network or not.  Presumably the
regulators have already decided what the requirements for emergency service
are for the cellular network (e.g. no SIM, SIM but ok if no credit, etc.),
and the handset meets those requirements.

The end result is that the building occupant satisfies the regulatory
requirement for "unauthenticated" emergency access without having to modify
their own network or VOIP deployment

From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 12:51 PM
To: Kroeselberg, Dirk (NSN - DE/Munich)
Cc: ext Bernard Aboba; [email-masked]
Subject: Re: [Ecrit] New work in ECRIT

Yeah, I'm as confused as Dirk here.  The IP network behind the femtocell
would still have to have a way to provide unauthenticated emergency calling,
just like any other IP network.  (I don't think it's possible to punt this
to IMS emergency calling, since that only covers the case where the VoIP
service being used is offered by the femtocell/IP-access provider.)

Are you saying the issue of how to get into a hotspot for emergency without
credentials will go away because there will be Femtocells around anyway? Not
sure this will be the general case soon.

However, there are also issues that apply to Femto access (not
subscribed/prepaid empty/CSG configurations etc). The idea is not to limit
considerations to one specific radio technology like WiFi.

Dirk

With femtocells, emergency calls (including non-service initialized ones)
can be made indoors, without the handset having to obtain access to a
corporate or hotspot network.  As a result, a company could forego the
challenge, expense and liability associated with engineering unauthenticated
emergency calling for non-employees. 

On Aug 3, 2010, at 12:12 PM, "Kroeselberg, Dirk (NSN - DE/Munich)"
<[email-masked]> wrote:

Bernard,

could you clarify your comment regarding the relation of femtocells to the
unauthenticated draft? It is correct that some femtocell configurations are
considered an issue for emergency access, but I am not sure which relation
to unauthenticated you are pointing at.

Thanks,

Dirk

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Bernard Aboba
Sent: Tuesday, August 03, 2010 7:26 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ecrit] New work in ECRIT

My humble suggestion is that draft-rosen-ecrit-additional-data is both
straightforward and highly beneficial.  While IETF tradition would suggest
that items with such a high benefit/cost ratio should be delayed
indefinitely or abandoned in favor of items that are more intractable,  I'd
suggest a concession to common sense in this isolated instance.

Of course, in order to ensure that the WG does not debase itself in an orgy
of productivity, tradition requires that the WG take on a number of work
items which are "hard" only because the wrong questions are being asked.
I'd assert that both Unauthenticated Access and PSAP callback  fall in this
category.   

Unauthenticated Access is "hard" because it represents a solution without a
real problem.  There is no regulatory requirement for this today, nor is
there likely to be one in the near future because the "solution" would
itself be a problem and because technology such as femtocells will make the
"problem" disappear in due course.

PSAP Callback is "hard" largely because of the disconnect between the PSTN
way of thinking and the reality of VOIP, which will result in extended (and
largely fruitless) "discussions", until the passage of the leaves the
obvious solution in plain view, like a whale washed up on the beach.
Serializing other work items until this "hard" problem is "solved" will
essentially cause them to wait in the queue until our teeth are but a
memory.