Subject: [Geopriv] NENA

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 15 Mar 2007 10:41:02 +0100

Hi all,

I would like to better understand the work done by NENA.

Which SDOs are going to make use (or is already used) of the work done 
by NENA?

Consider the following SDOs, as an example
- 3GPP
- 3GPP2
- Wimax
- Wifi Alliance
- DSL Forum
- ETSI TISPAN
- CableLabs

Since there is often a mismatch between the standards being developed in 
these SDOs I would like to also understand how the NENA work going to be 
used on the Internet?

Ciao
Hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 15 Mar 2007 05:28:02 -0500

ATIS 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 5:41 AM
To: GEOPRIV; ECRIT
Subject: [Ecrit] NENA

Hi all,

used on the Internet?

Ciao
Hannes

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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 15 Mar 2007 11:30:50 +0100

Hi Martin, 

what do you mean by "ATIS"?

You mean that ATIS is using the NENA architecture or I should have included ATIS in the list of SDOs? 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
> Gesendet: Donnerstag, 15. März 2007 11:28
> An: Hannes Tschofenig; GEOPRIV; ECRIT
> Betreff: [Geopriv] RE: [Ecrit] NENA
> 
> ATIS 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Mar 2007 06:46:37 -0500

I think Martin (the other Martin, not me) meant that ATIS works with NENA specifications. NENA is not an accredited SDO - in the same sense, for example, that ATIS is accredited and able to publish American National Standards. Of course, that doesn't prevent NENA from publishing referencable documents. The E2 interface specification used for wireless E-9-1-1 is a NENA document and, as ever, the i2 architecture specification is a NENA document.

I don't think there's anything prescriptive about how the work of NENA interacts with other SDOs. I think it's best understood in terms of the general role of NENA - which is to provide a national consensus view on how the elements of the emergency service fit together. This ends up covering everything from devices through access and core networks, and into the emergency network elements - the routers, call centers, and ALI and ANI databases.

This is particularly important in an environment such as the US which is extremely devolved with multiple independent parties operating at every level and every function. Without a body like NENA it would all deteriorate into chaos - despite how it seems to some, that's not what it is now. :)

It's good to look at a case study.

NENA had a lot of influence on, for example, the TIA J-STD-036 specification for phase 2 wireless which subsequently formed the deployment model for how the FCC mandate for wireless E-9-1-1 should be satisfied. This consequently had an impact on 3GPP/2. There are even parameters in the 3GPP MAP specification called NA-ESRK and NA-ESRD (the NA part stands for North American) - though they do actually have generic utility.

A typical chain of influence would go along the lines that US carriers need to meet some regulatory requirement for which definitions originating or influenced by NENA form the model for deployment. The carriers need their vendors to support the functionality associated with the model. Both the vendors and the carriers participate in the SDOs governing the specifications for the network elements involved and subsequently influence what those specifications look like. To a large extent, artefacts turn up in SDO specifications as an extended phenotype of the significance and influence of the US market and the role of NENA in that market.

Does that make sense? I'm not aware that there are any strict definitions for the relationship between NENA and other SDOs.

Cheers,
Martin

-----Original Message-----
From: Tschofenig, Hannes [mailto:[email-masked]] 
Sent: Thursday, 15 March 2007 9:31 PM
To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT
Subject: AW: [Geopriv] RE: [Ecrit] NENA

Hi Martin, 

Ciao
Hannes

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 15 Mar 2007 06:52:54 -0500

Yes 

-----Original Message-----
From: Tschofenig, Hannes [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 6:31 AM
To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT
Subject: AW: [Geopriv] RE: [Ecrit] NENA

Hi Martin, 

Ciao
Hannes

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 15 Mar 2007 12:57:36 +0100

Hi Martin, 

Thanks for the quick response. 

I am trying to figure out what the impact to the Internet is if many SDOs develop their own specifications for emergency services without considering the NENA work and I am particularly referring to the SDOs that potentially impact real networks. 

More comments below: 

> Von: Dawson, Martin [mailto:[email-masked]] 
> Gesendet: Donnerstag, 15. März 2007 12:47
> An: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes 
> Tschofenig; GEOPRIV; ECRIT
> Betreff: RE: [Geopriv] RE: [Ecrit] NENA
> 
> I think Martin (the other Martin, not me) meant that ATIS 
> works with NENA specifications. NENA is not an accredited SDO 
> - in the same sense, for example, that ATIS is accredited and 
> able to publish American National Standards. Of course, that 
> doesn't prevent NENA from publishing referencable documents. 
> The E2 interface specification used for wireless E-9-1-1 is a 
> NENA document and, as ever, the i2 architecture specification 
> is a NENA document.
> 
> I don't think there's anything prescriptive about how the 
> work of NENA interacts with other SDOs. I think it's best 
> understood in terms of the general role of NENA - which is to 
> provide a national consensus view on how the elements of the 
> emergency service fit together. This ends up covering 
> everything from devices through access and core networks, and 
> into the emergency network elements - the routers, call 
> centers, and ALI and ANI databases.
> 
> This is particularly important in an environment such as the 
> US which is extremely devolved with multiple independent 
> parties operating at every level and every function. Without 
> a body like NENA it would all deteriorate into chaos - 
> despite how it seems to some, that's not what it is now. :)
> 
> NENA had a lot of influence on, for example, the TIA 
> J-STD-036 specification for phase 2 wireless which 
> subsequently formed the deployment model for how the FCC 
> mandate for wireless E-9-1-1 should be satisfied. This 
> consequently had an impact on 3GPP/2.

>From the last SDO workshop I got the impression that the 3GPP2 actually had nothing expect for a few high-level requirements. Since a lot of the 3GPP2 work is taken from 3GPP it might well be possible that they also recycle the emergency services work. 

Maybe they have developed a solution already. Maybe you can point to the relevant documents. 

 There are even 
> parameters in the 3GPP MAP specification called NA-ESRK and 
> NA-ESRD (the NA part stands for North American) - though they 
> do actually have generic utility.

But the NENA work is more than just these parameters. 

> 
> A typical chain of influence would go along the lines that US 
> carriers need to meet some regulatory requirement for which 
> definitions originating or influenced by NENA form the model 
> for deployment. The carriers need their vendors to support 
> the functionality associated with the model. Both the vendors 
> and the carriers participate in the SDOs governing the 
> specifications for the network elements involved and 
> subsequently influence what those specifications look like. 
> To a large extent, artefacts turn up in SDO specifications as 
> an extended phenotype of the significance and influence of 
> the US market and the role of NENA in that market.

But it is not really good if the NENA work does not appear in the standardization work of other SDOs. 

> 
> Does that make sense? I'm not aware that there are any strict 
> definitions for the relationship between NENA and other SDOs.
It makes sense but to me it looks like the recipe for a non-working global emergency service solution since there are too many players involved that want to develop their own story. 

Ciao
Hannes

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 15 Mar 2007 08:13:11 -0400

DSL Forum is also using the NENA documents to determine requirements for network elements and CPE.
Barbara 

-----Original Message-----
From: Tschofenig, Hannes [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 7:58 AM
To: Dawson, Martin; Dolly, Martin C (Attlabs); Hannes Tschofenig; GEOPRIV; ECRIT
Subject: AW: [Geopriv] RE: [Ecrit] NENA

Hi Martin, 

More comments below: 

> An: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; 
> GEOPRIV; ECRIT
> I think Martin (the other Martin, not me) meant that ATIS works with 
> NENA specifications. NENA is not an accredited SDO
> - in the same sense, for example, that ATIS is accredited and able to 
> publish American National Standards. Of course, that doesn't prevent 
> NENA from publishing referencable documents.
> The E2 interface specification used for wireless E-9-1-1 is a NENA 
> document and, as ever, the i2 architecture specification is a NENA 
> document.
> 
> I don't think there's anything prescriptive about how the work of NENA 
> interacts with other SDOs. I think it's best understood in terms of 
> the general role of NENA - which is to provide a national consensus 
> view on how the elements of the emergency service fit together. This 
> ends up covering everything from devices through access and core 
> networks, and into the emergency network elements - the routers, call 
> This is particularly important in an environment such as the US which 
> is extremely devolved with multiple independent parties operating at 
> every level and every function. Without a body like NENA it would all 
> deteriorate into chaos - despite how it seems to some, that's not what 
> it is now. :)
> 
> J-STD-036 specification for phase 2 wireless which subsequently formed 
> the deployment model for how the FCC mandate for wireless E-9-1-1 
> should be satisfied. This consequently had an impact on 3GPP/2.

 There are even 
> parameters in the 3GPP MAP specification called NA-ESRK and NA-ESRD 
> (the NA part stands for North American) - though they do actually have 
> generic utility.

> 
> A typical chain of influence would go along the lines that US carriers 
> need to meet some regulatory requirement for which definitions 
> originating or influenced by NENA form the model for deployment. The 
> carriers need their vendors to support the functionality associated 
> with the model. Both the vendors and the carriers participate in the 
> SDOs governing the specifications for the network elements involved 
> and subsequently influence what those specifications look like.
> To a large extent, artefacts turn up in SDO specifications as an 
> extended phenotype of the significance and influence of the US market 
> and the role of NENA in that market.

Ciao
Hannes

> > Which SDOs are going to make use (or is already used) of the work 
> > done by NENA?
> > 
> This message is for the designated recipient only and may contain 
> privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender immediately 
> and delete the original.  Any unauthorized use of this email is 
> prohibited.

*****

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. GA621

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 15 Mar 2007 09:43:10 -0400

Martin D.,

As I have expressed in many NENA venues and will reiterate here, NENA goes
way past their boundary of expertise.  I've pleaded many times, for many
years (starting at the 2000 TDC), at many a microphone in NENA venues to
please provide the requirements they need to perform their function.  IMO,
no other organization can do that as well as NENA for North America.
If/when NENA does such, the IP/VoIP/Internet industry/SDO community
would/will provide the best solution possible to meet those requirements.

My statement didn't change over time: 'Please draw a line in the sand, on
one side is the world and the other side is NENA constituents, state the
requirements when crossing the line.'

Instead, many people have promoted to NENA members that they can not only
take NENA requirements to the SDO community, but that NENA can somehow
dictate the solution.

NENA's current review of location acquisition mechanisms is an example of
NENA crossing the line.  Those documents which have now filtered to ATIS
then liaised to a wide variety of SDOs 'on behalf of NENA' are fraught with
technical errors and misguided assumptions.  But, when the responses to the
liaise attempt to point out those issues, it's passed off as a derelict
response.  Further discussion of the ATIS process wrt this isn't warranted
in this venue.  But my point is that it seems to be common thread with what
we're experiencing in the IETF.

But, there is good in the world!

In my obviously biased opinion, I believe an example of what has worked is
the relationship between NENA and ECRIT.  I believe that LoST/related drafts
have met almost all, if not all of the goals/requirements of the NENA LTD
wg.  I did get a little testy when I (possibly mistakenly) sensed a late
change in requirements, but I sense that has resolved itself.  I've also
witnessed a willingness by the LoST team to make adjustments to the solution
as we/NENA gain implementation experience.  If that isn't an example of how
things should work, then all hope has vanished.

So, I ask that you compare the difference between the NENA-ECRIT
relationship and the NENA-GeoPriv relationship, what is your opinion of what
worked/didn't work/isn't working/and why?

Yes, NENA does count!  Threats of regulation do not count!

-Marc-

> From: Dawson, Martin [mailto:[email-masked]] 
> Sent: Thursday, March 15, 2007 7:47 AM
> To: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes 
> Subject: RE: [Geopriv] RE: [Ecrit] NENA
> 
> consequently had an impact on 3GPP/2. There are even 
> > Since there is often a mismatch between the standards being 
> developed 
> > in
> > 
> > these SDOs I would like to also understand how the NENA 
> work going to 
> > be
> > 
> > used on the Internet?
> > 
> > Ciao
> > Hannes
> > 
> >

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Mar 2007 09:19:59 -0500

This ends up being a bit of an essay - but it was the only way I felt I could respond to the question. The executive summary just says "I think the significance of these forums to the Internet depends on the nature of the forum." I know there's a mutual dependence between the Internet and these forums - in a very real way, neither would survive without the other.

1) A number of the forums are specialists in access technology. They care to the extent that convention and regulation impact the functionality they need to provide.

The IEEE, for example, reported at the SDO workshop in Columbia that they were considering dropping work on explicit location support because the "L7" approach was gaining focus - and because the NENA requirements were based on that model. They are now thinking that it's better to provide the mechanisms to deliver network measurement parameters by which a LIS could determine location - and subsequently package, deliver, and protect according to a general model, rather than provide a WiMAX specific mechanism to get location information to an end device. For them, it's kind of a relief that they don't have to push up into the application issues associated with location.

2) I'm not sure what the implications are for the "Internet". My suspicion is that there aren't particularly strong implications for it. Access technologies will continue to diversify and evolve as they have done for the last few decades. WiMAX, WiFi, Ethernet... none of them are technically just for IP access but the only market which permits them to become commodities is IP and the most common application for that is Internet access. I think the IEEE and other access forums will continue to try and keep their products relevant to that use.

3) In the case of 3GPP/2 however, we have a definite collision of worlds. They represent a complete end to end network architecture covering everything from devices through functional network elements, protocols, and even the services. While the architecture defines Packet Service (on top of the increasingly defunct Circuit Service) it is definitely not the same as being the Internet. Strictly speaking, IMS only has meaning within that constraint (even though the term is being used for a general Internet based VoIP service). The most significant convergence issue is between the likes of 3G and the general Internet model. The probability envelope still hasn't collapsed on whether 3G is primarily just another Internet access technology or whether it's a complete network itself - with Internet access bolted on the side as a peripheral function. I think market forces will not permit it to continue as a relatively complete but closed network - but that's just my view.

4) NENA, ETSI TISPAN, and similar organizations represent special interest groups that live on the Internet - I think we'll see increasing numbers of such organizations - NENA didn't used to worry about it, but now it does. The Internet is paying the price of its success; people wanted everyone to use it, now they do and they have things to say about how they'd like it to be. To some extent they will just want to refine their own applications and conventions but, also, they will seek to influence the functionality that is available in the Internet to make it optimal for their interests.

5) The role of the IETF in all this... I am not sure. I understand that in principal it may be the anointed party that ensures there is consistency and integrity to support global interoperability and some principles in support of users. When I look around, though, I see many many working groups focusing on very eclectic topics - and I'm not sure what sort of constitutional governance is used to really decide what's pertinet for the IETF and what might be better off having its own forum.

An alternative view would have been to say that "internet" means that it stops at the internetworking layer (layer 3 really) and that the Internet is the specific most significant global set of interconnected networks. From that perspective, the IETF would have made sure there was a consistent layer 3, including control functions (like DNS, DHCP, BGCP, etc.) but wouldn't sponsor applications - nor necessarily session, transport, and presentation layer technologies. In it's purest form the Internet is an openly connected set of layer 3 networks; a global platform for any number of applications. Voice is just a service, instant messaging is just a service, U-Tube is just a service... they all involve protocols and have interworking issues in their own domain but that's their problem and they shouldn't be able to impact a properly robust Internet. I think that's the virtue of the Internet over 3GPP/2 by the way - it's not as heavily prescriptive about what it is used for.

Of course - the IETF is not as I just suggested it could be - I said earlier what it looks like to me... confusing. In practice some of the application protocols are defined in the IETF and others are not. W3C was formed by Berners-Lee so he could pursue WWW principles independently of the IETF. It didn't really make any difference to the Internet that he did that - just added a terrific new application area with its own forum. It's certainly good that there's a place for people to go if they think they have a useful idea for something to do on the Internet but it certainly becomes a "grab bag". Perhaps it was because the IETF inherited other "stuff" like SMTP, FTP, and SNMP from the original ARPANet suite that opened the door to make it forum that's an application free for all... I don't know.

Cheers,
Martin

-----Original Message-----
From: Tschofenig, Hannes [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 7:58 AM
To: Dawson, Martin; Dolly, Martin C (Attlabs); Hannes Tschofenig; GEOPRIV; ECRIT
Subject: AW: [Geopriv] RE: [Ecrit] NENA

Hi Martin, 

 There are even 

Ciao
Hannes

> > developed in

*****

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Mar 2007 09:27:47 -0500

Hi Marc,

I don't know what you mean. NENA wrote requirements. The IETF is defining protocols. I think that's what you just said should happen.

The acquisition protocol comparison isn't a NENA document, it's an ESIF document. Perhaps you don't distinguish between them. Either way, it's in response to some industry demand for clarity on what they should be implementing. I think it's been worthwhile in bringing the requirements to the fore across a number of forums.

I haven't been involved in the NENA/ECRIT work, so I couldn't comment on how effective it's been.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, 16 March 2007 12:43 AM
To: Dawson, Martin
Cc: 'GEOPRIV'; 'ECRIT'
Subject: RE: [Geopriv] RE: [Ecrit] NENA

Martin D.,

-Marc-

---

From: "Abbott, Nadine B" <[email-masked]>
Date: Thu, 15 Mar 2007 10:49:30 -0400

Marc,

I think that you misrepresent the NENA WG work on location acquisition.

The NENA WG worked to provide requirements and to feed these requirements into the IETF Geopriv process, and it seems to me that many IETF Geopriv members have exerted considerable effort to consider how to include those requirements.
Many of those requirements were in fact, quite aligned with the related Long-Term Definition requirements provided to ECRIT. 

Further, the NENA WG then has tried to stay aware of what is going on in many industry forums in the expectation of  identifying and recommending standard solutions that would meet those requirements, and in the hope of promoting widespread implementation of location-related capabilities.  This is an ongoing work effort.

In the liaisons that were sent out to many SDOs last summer, the NENA WG encouraged these SDOs to work in cooperation with IETF toward common solutions. NENA has a keen interest in seeing common location solutions become widely available. In addition to this encouragement, the liaisons that were sent out included a summary of the above-mentioned requirements, as well as examples of proposed solution(s) that the NENA WG found to meet many of these requirements, to stimulate dialog.  

To my knowledge, the NENA WG has never "passed off as a derelict response" the responses that have been received from several SDOs to these liaisons.  

As you point out, IETF has the deepest understanding of the Internet, but it has always seemed to me that in the area of location capabilities, the community of mobile and IP service and solution providers have valuable insights to offer.  Members of the NENA WG have tried to advocate within IETF (and industry SDOs) for solutions that would meet practical needs of the emergency services community, and also have a better chance of being implemented in existing infrastructures beyond enterprise environments.

I am encouraged by Ted Hardie's comments and the hope that the Geopriv WG will be able to make some progress in the Prague meeting.  

Regards,
Nadine Abbott

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 9:43 AM
To: 'Dawson, Martin'
Cc: 'GEOPRIV'; 'ECRIT'
Subject: RE: [Geopriv] RE: [Ecrit] NENA

Martin D.,

As I have expressed in many NENA venues and will reiterate here, NENA goes way past their boundary of expertise.  I've pleaded many times, for many years (starting at the 2000 TDC), at many a microphone in NENA venues to please provide the requirements they need to perform their function.  IMO, no other organization can do that as well as NENA for North America.
If/when NENA does such, the IP/VoIP/Internet industry/SDO community would/will provide the best solution possible to meet those requirements.

My statement didn't change over time: 'Please draw a line in the sand, on one side is the world and the other side is NENA constituents, state the requirements when crossing the line.'

Instead, many people have promoted to NENA members that they can not only take NENA requirements to the SDO community, but that NENA can somehow dictate the solution.

NENA's current review of location acquisition mechanisms is an example of NENA crossing the line.  Those documents which have now filtered to ATIS then liaised to a wide variety of SDOs 'on behalf of NENA' are fraught with technical errors and misguided assumptions.  But, when the responses to the liaise attempt to point out those issues, it's passed off as a derelict response.  Further discussion of the ATIS process wrt this isn't warranted in this venue.  But my point is that it seems to be common thread with what we're experiencing in the IETF.

In my obviously biased opinion, I believe an example of what has worked is the relationship between NENA and ECRIT.  I believe that LoST/related drafts have met almost all, if not all of the goals/requirements of the NENA LTD wg.  I did get a little testy when I (possibly mistakenly) sensed a late change in requirements, but I sense that has resolved itself.  I've also witnessed a willingness by the LoST team to make adjustments to the solution as we/NENA gain implementation experience.  If that isn't an example of how things should work, then all hope has vanished.

So, I ask that you compare the difference between the NENA-ECRIT relationship and the NENA-GeoPriv relationship, what is your opinion of what worked/didn't work/isn't working/and why?

-Marc-

> To: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; 
> GEOPRIV; ECRIT
> should be satisfied. This consequently had an impact on 3GPP/2. There 
> are even parameters in the 3GPP MAP specification called NA-ESRK and 
> NA-ESRD (the NA part stands for North American) - though they do 
> actually have generic utility.
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 15 Mar 2007 11:21:22 -0400

On Mar 15, 2007, at 10:49 AM, Abbott, Nadine B wrote:

> The NENA WG worked to provide requirements and to feed these  
> requirements into the IETF Geopriv process, and it seems to me that  
> many IETF Geopriv members have exerted considerable effort to  
> consider how to include those requirements.
> Many of those requirements were in fact, quite aligned with the  
> related Long-Term Definition requirements provided to ECRIT.
>
> Further, the NENA WG then has tried to stay aware of what is going  
> on in many industry forums in the expectation of  identifying and  
> recommending standard solutions that would meet those requirements,  
> and in the hope of promoting widespread implementation of location- 
> related capabilities.  This is an ongoing work effort.

I'm currently sitting in a NENA NG Partner Program meeting in  
Arlington, VA.  One of the presentations was a list of the SDOs that  
NENA has reached out to, with the IETF left off the list.  When  
questioned about that, the response was (summarizing) "Working with  
the IETF is a given.  We work with them every day."

I think some of the frustration around the requirements has been  
that, from the perspective of many IETF'ers, the requirements from  
NENA have been thrown over the wall, they are done as far as NENA is  
concerned, and that the IETF has no right to question them.  I do not  
believe that was the intent, because I know many NENA active  
participants have been active in GEOPRIV and ECRIT.  From the other  
perspective, I'm sure NENA participants see the IETF reacting badly.

In the future, both organizations should strive to work together  
during the requirements development.  I personally I have casually  
pursued getting the IETF to have an official liaison to NENA, but the  
IAB has not exactly been receptive of the idea.  I think it is time  
that the ECRIT and GEOPRIV co-chairs push harder on the IAB to  
establish an official relationship if NENA is willing to allow it.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 15 Mar 2007 11:45:55 -0400

Nadine,

> Further, the NENA WG then has tried to stay aware of what is 
> going on in many industry forums in the expectation of  
> identifying and recommending standard solutions that would 
> meet those requirements, and in the hope of promoting 
> widespread implementation of location-related capabilities.  
> This is an ongoing work effort.

It is the act of NENA 'recommending standard solutions' that I am referring
to.  IMO, that is outside of NENA's expertise.

> 
> In the liaisons that were sent out to many SDOs last summer, 
> the NENA WG encouraged these SDOs to work in cooperation with 
> IETF toward common solutions. NENA has a keen interest in 
> seeing common location solutions become widely available. In 
> addition to this encouragement, the liaisons that were sent 
> out included a summary of the above-mentioned requirements, 
> as well as examples of proposed solution(s) that the NENA WG 
> found to meet many of these requirements, to stimulate dialog.

I wasn't specifically referring to the liaisons from NENA last summer, sorry
that wasn't clear, but I was focused on NENA's new found agent, ESIF/NGES.
It's very interesting on how Martin is characterizing these latest liaisons
from NGES as an ESIF effort, but yet in that very venue when I questioned
why normal ANSI engineering practices were not being exercised, I was told
to go back to NENA if I questioned the requirements.  So either that effort
is an ESIF project requiring due ANSI proscribed engineering, or ESIF/NGES
is an agent for NENA as was explained to me in that venue.  Martin is
changing the characterization of this project to fit his needs in the
current conversation.

> 
> To my knowledge, the NENA WG has never "passed off as a 
> derelict response" the responses that have been received from 
> several SDOs to these liaisons.

Again, this is my opinion of how NGES is handling responses to their
liaison, sorry for the confusion.

> 
> As you point out, IETF has the deepest understanding of the 
> Internet, but it has always seemed to me that in the area of 
> location capabilities, the community of mobile and IP service 
> and solution providers have valuable insights to offer.  
> Members of the NENA WG have tried to advocate within IETF 
> (and industry SDOs) for solutions that would meet practical 
> needs of the emergency services community, and also have a 
> better chance of being implemented in existing 
> infrastructures beyond enterprise environments.

So, come one and all with requirements.  When consensus on requirements is
achieved, come one and all with solution proposals.  I've tried to
demonstrate with the ECRIT example how that process works and at the same I
believe we've witnessed how it doesn't work by bringing the requirements
along with a proposed solution in what appears to be a mixed up sequence.

> 
> I am encouraged by Ted Hardie's comments and the hope that 
> the Geopriv WG will be able to make some progress in the 
> Prague meeting.

I have great hope for this effort.  I hope Ted can provide the spark to get
things moving forward.  I know I'm tired of trying.

-Marc-

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Thu, 15 Mar 2007 09:53:02 -0600

Hannes -

A really interesting question - especially from the perspective of location 
payloads and location provision. We in the OGC struggle with this issue on a 
regular basis. This is perhaps why the OGC has formal agreements with about 
a dozen SDOs and other organizations that develop specifications in the 
location/geospatial space. And even with lots of coordination and 
collaboration, sometimes folks go their own way - which plays havoc with 
consistent architecture and infrastructure. And we find new efforts cropping 
up on a regular basis.

That said, from a standards "professional" perspective, I am very pleased 
with how the IETF GeoPRIV collaboration and standard work is progressing. I 
know that there is a bit of concern about discord in some of the recent 
discussions . . . but compared to some standards discussions I have 
witnessed over the years, the ones in the GeoPRIV WG are consistently 
professional and well mannered!

Regards

Carl

----- Original Message ----- 
From: "Tschofenig, Hannes" <[email-masked]>
To: "Dawson, Martin" <[email-masked]>; "DOLLY, MARTIN C, ATTLABS" 
<[email-masked]>; "Hannes Tschofenig" <[email-masked]>; "GEOPRIV" 
<[email-masked]>; "ECRIT" <[email-masked]>
Sent: Thursday, March 15, 2007 5:57 AM
Subject: AW: [Geopriv] RE: [Ecrit] NENA

> I am trying to figure out what the impact to the Internet is if many SDOs 
> develop their own specifications for emergency services without 
> considering the NENA work and I am particularly referring to the SDOs that 
> potentially impact real networks.
>
> More comments below:
>
>>From the last SDO workshop I got the impression that the 3GPP2 actually 
>>had nothing expect for a few high-level requirements. Since a lot of the 
>>3GPP2 work is taken from 3GPP it might well be possible that they also 
>>recycle the emergency services work.
>
> It makes sense but to me it looks like the recipe for a non-working global 
> emergency service solution since there are too many players involved that 
> want to develop their own story.
>
>
> Ciao
> Hannes
>
>
>> Cheers,
>> Martin
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Mar 2007 13:33:29 -0400

I am the chair of the Long Term Definition Working Group in NENA.  We are
developing a specification currently entitled "Functional and Interface
Requirements for Next Generation 9-1-1 (i3)".  The central concept to i3 is
the Emergency Services IP Network, which is a managed IP network to which
all public safety agencies will be connected.  The ESInet, which WILL be
connected to the Internet, is the entry point for emergency calls, but it is
also used among public safety agencies to exchange calls and data.

The above referenced document has a defined scope.  That scope is the
interface for calls and asynchronous events from access networks (including
the Internet), and the 9-1-1 system, coming into the ESInet and things
within the ESInet itself.  After a transition period, ALL calls and events
will enter the ESInet through an i3 defined interface.  A succinct
definition of that interface is "SIP, with location and call back, routed by
LoST".  We may support other interfaces (e.g. XMPP).  There will be an
asynchronous event interface.  The scope does not include what happens
inside a PSAP, but does include the external interfaces it exposes and uses.

The working group is intimately familiar with, and attempts to work with
ecrit to make sure that the interface it defines aligns with the work of
ecrit.  The interface for multimedia calls will be SIP, and should conform
to the -framework and -phonebcp documents.  The scope of i3 is slightly
bigger than the edge of the ESInet, because it includes the "Emergency Call
Routing Function" (ECRF) which is the database callers use to route calls to
an Emergency Services Routing Proxy (ESRP) which sits at the edge of the
ESInet.  The ECRF will have a LoST interface.  

Any carrier who delivers calls via IP to a PSAP in North America, will be
required to use the NENA interface, since that is the only interface that
will be supported.  During transition, other interfaces may be supported,
and of course, existing interfaces will be supported for some time during
transition.  PSAPs presently define their interfaces, and carriers are
required to conform to them.  That will not change.  Carriers don't get to
make up their own interface and demand the PSAP conform to that.  On the
other hand, PSAPs, and NENA, don't get to tell carriers how to build their
networks.  We only define the interface, and, in this case, supply databases
for routing and validation.

A draft of the document was liaisoned to a number of SDOs for comments.  We
are reluctant to put the document on a public website, since it is just a
draft, and NENA policies to not permit drafts of its standards to be
publicly available.  I would have to get the group and NENA's concurrence,
but if there are members of ecrit who cannot get the document by another
path, I can probably arrange to email it to you.

LTD has, on a number of occasions, sent requirements to ecrit.  This has
been done in the usual informal way, as an email or an Internet Draft
submitted by an individual.  We discuss ecrit drafts in our meeting, achieve
consensus on what we would like to see happen, and delegate individuals to
pursue the changes we want.  Theresa Reese has recently been fulfilling that
role with respect to the LoST drafts. 

In the NENA division of labor, location for NG9-1-1 is the province of a
different working group (the "VoIP Location Working Group"), which has
different leadership, but similar style.  They mainly deal with geopriv.

While a formal liaison relationship with NENA is possible, I don't feel we
need one.  NENA, like IETF, can do formal liaisons, but the organization is
not an SDO, and doesn't really have a great process for liaisons.  It would
be nice to have a better way to get document drafts to IETF folks.

I hope this is a sufficient explanation of NENAs work on IP based interfaces
to emergency calls, the scope of its current work in that area, the way it
thinks it interacts with IETF, and how it expects its work product to be
used.  If you have any questions, I would be please to answer them.

Brian Rosen
Chair
Long Term Definition Working Group
VoIP/Packet Technical Committee
NENA

Note: This email is my personal opinion and does not represent any
discussions in NENA

---

From: Andrew Newton <[email-masked]>
Date: Thu, 15 Mar 2007 15:30:59 -0400

> be nice to have a better way to get document drafts to IETF folks.

Brian,

The IETF has liaison relationships with organizations that are not  
typically classified as SDOs.  ICANN is a big example.  I would also  
disagree about NENA not being an SDO, as they appear to be publishing  
standards in the context of these conversations.  The standards may  
not be typical technical wire protocol specifications, but  
requirements can also be standards.  I just had a conversation with  
Roger Hixson about the possibility of a formal liaison, and he  
believes it to be appropriate.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Mar 2007 15:41:47 -0400

Okay, just so you know what you are asking for.

For my group to send an email to the ecrit or geopriv list, we discuss it in
a conference call, we MAY (but often don't) pass around a draft, and we
designate some one to send it.

To get a liaison out, we fill out a form, hold a semi-official vote, send it
to the "tech lead team", which includes Roger.  They approve it, and then
Roger sends it.  So far, the average time to get through that process is
between one and three months, although everyone agrees that is ridiculous,
and we should be able to get it down to a couple of weeks.

So sure, we can have a formal liaison if you want one.

Brian

  _____  

From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 3:31 PM
To: Brian Rosen
Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT'
Subject: Re: [Geopriv] RE: [Ecrit] NENA

Brian,

The IETF has liaison relationships with organizations that are not typically
classified as SDOs. ICANN is a big example. I would also disagree about NENA
not being an SDO, as they appear to be publishing standards in the context
of these conversations. The standards may not be typical technical wire
protocol specifications, but requirements can also be standards. I just had
a conversation with Roger Hixson about the possibility of a formal liaison,
and he believes it to be appropriate.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Mar 2007 10:56:40 -0400

On Mar 15, 2007, at 3:41 PM, Brian Rosen wrote:
> To get a liaison out, we fill out a form, hold a semi-official  
> vote, send it to the “tech lead team”, which includes Roger.  They  
> approve it, and then Roger sends it.  So far, the average time to  
> get through that process is between one and three months, although  
> everyone agrees that is ridiculous, and we should be able to get it  
> down to a couple of weeks.

All I ever wanted to do was write software.  How did I get myself  
into this mess?

-andy