I will be linking to this post from most of my other posts about #E911 and #NG911. It’s meant to be an introduction to who I am, and where I’m coming from.
I’ve been around a while. I learned to code in 1965, and I haven’t stopped yet, although I consider myself a lousy coder. I can get the job done, but that’s about it. I’ve been a system’s architect, and hardware/software team leader since around 1978 and think I’m pretty good at that. I know networking fairly well. I was on the machine room floor when the ARPAnet IMP was winched into Carnegie-Mellon’s Computer Science Department. I learned about Ethernet from Bob Metcalfe while I was working at Xerox Palo Alto Research Center (PARC) where I did hardware design on the “D” machines. I’ve been dealing with network protocol design and implementation since then.
I’ve been a founder of 5 start-ups, and President/CEO of 3 of them. Nothing hit big, but we made a difference in a few areas. Relevant to what I’ll be writing about, two of the start-ups were in the medical devices field. When you create software for medical devices, you learn that while you can’t eliminate bugs, you can make sure you don’t hurt people. The notion that limiting damage can be more important that correct operation is a bias I carry.
I’ve been working in computer graphics in one form or another nearly my entire professional life. I’ve done hardware design and software for lots of different graphics systems from stroke writers (look it up) to telepresence systems. In the latter, we managed to get a good grounding in high quality user interface design, including human factors research, interaction design, graphics design and usability testing/optimization. I learned that good UI is a science, not just an art and it’s possible to engineer a good UI, test it, and make it work well. I’m appalled at the UI in most of the systems I’ll be writing about.
Very early in my career, I got to go to a seminar on quality assurance that was taught by W. Edwards Deming, his associates and disciples. It was eye opening, and I will never forget listening to him explain what it took to get to high quality results. If you will permit me to relate one of his more memorable examples: he explained “Zero Defects” this way: “How many babies is a delivery nurse allowed to drop?” Does it ever happen? Yes, it does. But what is the requirement? Zero of course. And if it ever does happen, that is a deviation from the standard and requires corrective action. Thus began my fascination with quality.
I did a stint at FORE Systems, which was acquired by Marconi, and was a premier supplier of Asynchronous Transfer Mode (ATM) switches for enterprise, government and Tier 1 ISPs. I was fortunate to get a real education in building 5 nines availability systems at FORE. They employed a skilled reliability engineer who really knew his stuff, and I got to learn what goes in to really achieving 5 nines. FORE had (painfully) learned to build such systems and I got there just after they had finally made it work for real. They had the zeal of the recently converted and I got indoctrinated in what it actually takes.
In the last two years, I helped the quality assurance team improve overall quality at Neustar. One of my primary contributions was a ringleader in our Change Control Board efforts. A couple of us got pretty good at asking the right questions and insisting on meeting the process standards. I did reviews of Root Cause Analysis reports. I also ran a team that built a cloud based external monitoring system that monitors most of Neustar’s many services from outside the company’s network and colo sites. So I have recent experience building public cloud based services. I’ve also done some work on software development methodology and tools. I’m a big believer in Continuous Integration, Containers and Test Driven Development.
I’ve been a professional standards geek for the last 20 years. My first IETF meeting was IETF 43 in Orlando, back in 1998 and I haven’t missed many since. I started working in Megaco/H.248, and I was the IETF editor for that work (RFC 3015). I then became the co-chair for the sip working group, and I was chair when the base document for SIP, RFC 3261 was published. I was responsible for the ABNF in that document, which, alas, has several errata 🙁 I am presently the co-chair of sipcore, the main SIP protocol working group. I also authored or co-authored many of the IETF documents on emergency calling, which is the basis for Next Generation 9–1–1.
While I was working on SIP, and VoIP in general, we realized that until we made emergency calling (9–1–1, 1–1–2, …) work, VoIP would not take off. About the same time, the 9–1–1 system began receiving calls from VoIP systems. They had just gotten 9–1–1 from mobile phones to work after the mobile operators insisted no one would use a cell phone to call 9–1–1. Today, over 80% of 9–1–1 calls are from mobiles. It was déjà vu all over again. The NENA guys went looking for VoIP expertise and IETF guys went looking for 9–1–1 expertise. We found each other.
There was a meeting arranged by Tom Breen in Atlanta where several IETFers, including me, met with several NENA folks. Out of that meeting came a three part plan:
- i1: document how the then-current VoIP systems implemented 9–1–1 (badly, if at all)
- i2: Design and document the right way to support VoIP in the current E9–1–1 system
- i3: Design an entirely new 9–1–1 system based on Internet Protocol
I was a major contributor to the i2 effort (NENA 08–001), and since the initiation, have been the chair or co-chair of the i3 working group in NENA, which is the technical standard for what is called Next Generation 9–1–1. I was the editor for the first version of the standard (NENA 08–003) and I have written a great deal of the text in the current version, NENA-STA-010.2, and the forthcoming Version 3 release, NENA-STA-010.3. I also am a major contributor to several other NENA documents including the security document NENA-INF-015, and the ESInet design document, NENA-INF-016.2.
Early in my work with NENA, I met Richard Ray and Donna Platt, among others, who work to make sure 9–1–1 works for deaf and hard of hearing persons. I have maintained an active interest in making sure our work significantly improves how we serve this important constituency in emergency calling. As it happened, in my day job at Neustar, we bid on, and won a contract with the FCC to design, deploy and operate the iTRS Directory, which is a database that allows deaf and hard hearing persons using Video Relay Service to call each other and to port their telephone numbers from one VRS Provider to another. That service was operated at a 5 nines availability SLA. It had a failure in the first two years where we did not achieve 5 nines, but it has met that standard for 7 years since then. I have excellent relationships with several staffers and officials at the FCC.
I do not consider myself a security expert. I know several, and I’m not one of them. I was at the beanbag lecture by Ron Rivest (the “R” in RSA) where he described public key cryptography for the first time anyone at PARC had heard about it. There were 3 implementations by the next day. I nevertheless frequently find myself the most knowledgeable security guy in the room, which is weird to me. I did nearly all the original security design of Next Generation 9–1–1, although we now have several folks who contribute. Neustar operated one of the largest DDoS mitigation services in the world, and I learned a bit about how that works. So, frequently, I will opine about security in NG9–1–1, but remember, I’m not a real expert.
So, that’s me: hardware/software engineer, systems architect, team leader, entrepreneur, graphics/video guy, quality obsessed, standards geek, sip expert, NG9–1–1 pioneer, and a bit of security. I’ve designed, built, deployed, sold, maintained and operated dozens of systems. Been there, done that. I retired from Neustar in 2018 and am now consulting, mostly to state governments who are, or are planning to, deploy NG9–1–1. I usually work with a larger consulting group for these assignments. I do some other consulting besides that. In my postings, I’m aiming both to get vendors to improve what they are offering, and to help 9–1–1 Authorities ask for the right things. I’ve always been a vendor, so that’s the side I’m coming from. I really do understand what it takes to run a profitable business. But this, like the delivery room Dr. Deming talked about, this is 9–1–1. People’s lives are at stake. Zero defects and five nines aren’t just slogans to me.
You can reach me at br@brianrosen.net. I’m @brian_rosen on Twitter. If you are involved in public safety or emergency communications, join my LinkedIn network.
Leave a comment