RE: [Geopriv] RE: [Ecrit] NENA

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:mlinsner@cisco.com]
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.

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-

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Thursday, March 15, 2007 7:47 AM
> To: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig;
> GEOPRIV; ECRIT
> Subject: 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. :)
>
> 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:hannes.tschofenig@siemens.com]
> 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,
>
> 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:mdolly@att.com]
> > Gesendet: Donnerstag, 15. März 2007 11:28
> > An: Hannes Tschofenig; GEOPRIV; ECRIT
> > Betreff: [Geopriv] RE: [Ecrit] NENA
> >
> > ATIS
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Thursday, March 15, 2007 5:41 AM
> > To: GEOPRIV; ECRIT
> > Subject: [Ecrit] NENA
> >
> > 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
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
> --------------------------------------------------------------
> ----------------------------------
> 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]
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 15 Mar 2007 10:49:30 -0400