RE: [Geopriv] RE: [Ecrit] NENA

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:mlinsner@cisco.com] Sent: Friday, 16 March 2007 12: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 ------------------------------------------------------------------------------------------------ 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
Received on Thu, 15 Mar 2007 09:27:47 -0500