idnits 2.17.1 draft-ietf-geopriv-local-civic-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2011) is 4767 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 323 -- Looks like a reference, but probably isn't: '1' on line 324 == Missing Reference: 'XX' is mentioned on line 330, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNS' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: Standards Track Andrew Corporation 5 Expires: September 12, 2011 R. Barnes 6 BBN Technologies 7 B. Rosen 8 NeuStar, Inc. 9 R. George 10 Huawei Technologies 11 March 11, 2011 13 Specifying Civic Address Extensions in PIDF-LO 14 draft-ietf-geopriv-local-civic-01 16 Abstract 18 New fields are occasionally added to civic addresses. A backwardly- 19 compatible mechanism for adding civic address elements to the Geopriv 20 civic address format is described. A formal mechanism for handling 21 unsupported extensions when translating between XML and DHCP civic 22 address forms is defined for entities that need to perform this 23 translation. Intial extensions for some new elements are also 24 defined. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Specifying Civic Address Extensions . . . . . . . . . . . . . 4 64 3. Translating Unsupported Elements . . . . . . . . . . . . . . . 5 65 3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6 66 3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6 67 3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7 68 3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 7 69 4. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 9 73 4.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 9 74 4.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 10 75 4.6. Extension examples . . . . . . . . . . . . . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 6.1. CAtype Registration for Extensions . . . . . . . . . . . . 11 79 6.2. End of Numeric CAtype Registration . . . . . . . . . . . . 11 80 6.3. URN sub-namespace registration for 81 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' . . 11 82 6.4. XML Schema Registration . . . . . . . . . . . . . . . . . 12 83 6.5. Registration Template . . . . . . . . . . . . . . . . . . 12 84 6.6. Registration Policy and Expert Guidance . . . . . . . . . 14 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 The Geopriv civic location specifications ([RFC4776], [RFC5139]) 94 define an XML and binary representtations for civic addresses that 95 allow for the expression of civic addresses. Guidance for the use of 96 these formats for the civic addresses in different countries is 97 included in [RFC5774]. 99 Subsequent to these specifications being produced, use cases for 100 extending the civic address format with new elements have emerged. 101 Extension elements do not readily fit existing elements, as 102 recommended in [RFC5774]. 104 The XML format for civic addresses [RFC5139] provides a mechanism 105 that allows for the addition of standardized or privately understood 106 elements. A similar facility for private extension is not provided 107 for the DHCP format [RFC4776], though new specifications are able to 108 define new CAtypes (civic address types). 110 A recipient of a civic address in either format currently has no 111 option other than to ignore elements that it does not understand. 112 This results in any elements that are unknown to that recipient being 113 discarded if a recipient performs a translation between the two 114 formats. In order for a new extension to be preserved through 115 translation by any recipient, the recipient has to understand the 116 extension and know how to correlate an XML element with a CAtype. 118 This document describes how new civic address elements are added. 119 Extension always starts with the definition of XML elements. A 120 mechanism for carrying the extension in the DHCP format is described. 121 A new XML namespace containing a small number of additional civic 122 elements is also defined and can be used as a template to illustrate 123 how other extensions can be defined as required. 125 These mechanisms ensure that any translation between formats can be 126 performed consistently and without loss of information. Translation 127 between formats can occur without knowledge of every extension that 128 is present. 130 These additions described in this document are backwardly compatible. 131 Existing implementations may cause extension information to be lost, 132 but the presence of extensions does not affect an implementation that 133 conforms to either [RFC4776] or [RFC5139]. 135 1.1. Motivating Example 137 One instance where translation might be necessary is where a device 138 receives location configuration using DHCP [RFC4776]. Conversion of 139 DHCP information to an XML form is necessary if the device wishes to 140 use the DHCP-provided information in a range of applications, 141 including location-based presence services [RFC4079], and emergency 142 calling [RFC5012]. 144 +--------+ +--------+ +-----------+ 145 | DHCP | DHCP | Device | XML | Recipient | e.g., Presence 146 | Server |--------->| |-------->| | Agent 147 +--------+ +--------+ +-----------+ 149 Conversion Scenario 151 The Device that performs the translation between the DHCP and XML 152 formats might not be aware of some of the extensions that are in use. 153 Without knowledge of these extensions and how they are represented in 154 XML, the Device is forced to discard them. 156 These extensions could be useful - or critical - to the ultimate 157 consumers of this information. For instance, an extension element 158 might provide a presence watcher with important information in 159 locating the Device or an extension might be significant in choosing 160 a particular call route. 162 1.2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 2. Specifying Civic Address Extensions 170 The civic schema in [RFC5139] defines an ordered structure of 171 elements that can be combined to describe a civic address. The XML 172 extension point at the end of this sequence is used to extend the 173 address. 175 New elements are defined in a new XML namespace [XMLNS]. This is 176 true of address elements with significance within private or 177 localized domains, as well as those that are intended for global 178 applicability. 180 New elements SHOULD use the basic "caType" schema type defined in 181 [RFC5139]. This type provides an optional "xml:lang" attribute. 183 For example, suppose the (fictitious) Central Devon Canals Authority 184 wishes to introduce a new civic element called "bridge". The 185 authority defines an XML namespace that includes a "bridge" element. 187 The namespace needs to be a unique URI, for example 188 "http://devon.canals.org.uk/civic". 190 A civic address that includes the new "bridge" element is shown in 191 Figure 1. 193 196 UK 197 Devon 198 Monkokehampton 199 Deckport 200 Cross 202 21451338 204 206 Figure 1: Extended Civic Address Example 208 An entity that receives this location information might not 209 understand the extension address element. As long as the added 210 element is able to be safely ignored, the remainder of the civic 211 address can be used. The result is that the information is not as 212 useful as it could be, but the added element does not prevent the use 213 of the remainder of the address. 215 The address can be passed to other applications, such as a LoST 216 server [RFC5222], without modification. If the application 217 understands the added elements, it is able to make use of that 218 information. For example, if this civic address is acquired using 219 HELD [RFC5985], it can be included in a LoST request directly. 221 3. Translating Unsupported Elements 223 Unsupported civic address elements can be carried without consequence 224 only as long as the format of the address does not change. When 225 converting between the XML and DHCP formats, these unsupported 226 elements are necessarily discarded: the entity performing the 227 translation has no way to know the correct element to use in the 228 target format. 230 All extensions MUST be defined using the mechanism described in this 231 document. Extensions that use numeric CAtypes or other mechanisms 232 cannot be safely translated between XML and DHCP representations. 234 An entity that does not support these extension mechanisms is 235 expected to remove elements it doesn't understand when performing 236 conversions. 238 3.1. XML to DHCP Format Translation 240 Extensions to the XML format [RFC5139] are defined in a new XML 241 namespace [XMLNS]. 243 Extensions in the XML format can be added to a DHCP format civic 244 address using an extension CAtype. 246 3.2. Extension Civic Address Type (CAtype) 248 The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor: 249 please replace XX here and in the figure below with the assigned 250 code] includes three values that uniquely identify the XML extension 251 and its value: a namespace URI, the local name of the XML element, 252 and the text content of that element. These three values are all 253 included in the value of the CAtype, each separated by a single 254 whitespace character. 256 0 1 2 3 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | CAtype (XX) | Length | Namespace URI ... . 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 . Namespace URI (continued) ... . 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Space (U+20) | XML element local name ... . 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Space (U+20) | Extension type value ... . 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 2: XML Civic Address Extension CAtype 270 The content of a CAtype (after the CAtype code and length) is UTF-8 271 encoded Unicode text [RFC3629]. A maximum of 255 octets is allowed. 272 Octets consumed by the namespace URI and local name reduce the space 273 available for values. 275 This conversion only works for elements that have textual content and 276 an optional "xml:lang" attribute. Elements with complex content or 277 other attributes - aside from namespace bindings - MUST be ignored if 278 they are not understood. 280 3.3. DHCP to XML Format Translation 282 The registration of a new CAtype following the process in [RFC4776] 283 means that a recipient that does not know the equivalent XML is 284 unable to produce a complete XML representation of the DHCP civic 285 address. For this reason, this document ends the registration of new 286 numeric CAtypes. No new registrations of numeric CAtypes can be 287 made. 289 In lieu of making new numerical CAtype assignments, this document 290 creates a new extensionCA type which is defined in a manner that lets 291 new civic elements be described in DHCP form by carrying the name 292 space and type name of the extension in parameters of the extensionCA 293 type. 295 When converting to XML, the namespace prefix used for the extension 296 element is selected by the entity that performs the conversion. 298 3.4. Conversion Example 300 The following example civic address contains two extensions: 302 306 US 307 CA 309 2471 310 AQ-374-4(c) 312 LAX 313 Tom Bradley 314 G 315 36B 316 318 Figure 3: XML Example with Multiple Extensions 320 This is converted to a DHCP form as follows: 322 country = US 323 CAtype[0] = en-US 324 CAtype[1] = CA 325 CAtype[XX] = http://postsoftheworld.net/ns lamp 2471 326 CAtype[XX] = http://postsoftheworld.net/ns lamp AQ-374-4(c) 327 CAtype[XX] = http://example.com/airport/5.0 airport LAX 328 CAtype[XX] = http://example.com/airport/5.0 terminal Tom Bradley 329 CAtype[XX] = http://example.com/airport/5.0 concourse G 330 CAtype[XX] = http://example.com/airport/5.0 gate 36B 332 Figure 4: Converted DHCP Example with Multiple Extensions 334 4. Civic Extensions 336 We use this new extension method to define some additional civic 337 address elements which are needed to correctly encode civic locations 338 in several countries. The definition of these new civic address 339 elements also serves as an example of how to define additional 340 elements using the mechanisms described in this document. 342 4.1. Pole Number 344 In some areas, utility and lamp posts carry a unique identifier, 345 which we call a pole number in this document. In some countries, the 346 label on the lamp post also carries the local emergency service 347 number, such as "110", encouraging callers to use the pole number to 348 identify their location. 350 _.-----,===. 351 | | (''''') 352 | | `---' 353 | | 354 | | ,---------, 355 | | ,---, |Emergency| 356 | | /|,-.|----->| Number | 357 | | / |110| '---------' 358 | | / |`-'| 359 |_|/ | 2 | ,---------, 360 | | | 1 | |Lamp Post| 361 | | | 2 |----->| Number | 362 |-| | 1 | '---------' 363 | |\ | 0 | 364 | | \ | 1 | 365 | | \ | 4 | 366 | | \|,,,| 367 _ | | 368 ``-..|.| 369 ``--.._ 370 `'--.._ 372 Figure 5: Lamp post with emergency number 374 4.2. Mile Post 376 On some roads, and many trails, railroad rights of way and other 377 linear features, a post with a mile or kilometer distance from one 378 end of the feature may be found (a "milepost"). There are other 379 cases of poles or markers with numeric indications that are not the 380 same as a "house number" or street address number. 382 4.3. Street Type Prefix 384 The civic schema defined in [RFC5139] allows the definition of 385 address "123 Colorado Boulevard", but it does not allow for the easy 386 expression of "123 Boulevard Colorado". Adding a street-type prefix, 387 allows street named in this manner to be more easily represented. 389 4.4. House Number Prefix 391 The civic schema defined in [RFC5139] provides house number suffix 392 element, allowing one to express an address like "123A Main Street", 393 but it does not contain a corresponding house number prefix. The 394 house number prefix element allows the expression of address such as 395 "Z123 Main Street". 397 4.5. XML Extension Schema 399 400 408 410 411 413 414 416 417 419 420 422 424 4.6. Extension examples 426 US 430 CA 431 Sacramento 432 I5 433 248 434 22-109-689 435 437 XML Example with Post Number and Mile Post 439 US 443 CA 444 Sacramento 445 Colorado 446 223 447 Boulevard 448 A 449 451 XML Example with Street prefix and House Number Prefix 453 5. Security Considerations 455 This document defines a formal way to extend the existing Geopriv 456 civic address schema. No security threats are introduced by this 457 document. 459 Security threats applicable to the civic address formats are 460 described in [RFC4776] (DHCP) and [RFC5139] (XML). 462 6. IANA Considerations 464 This document alters the "CAtypes" registry established by [RFC4776]. 466 6.1. CAtype Registration for Extensions 468 IANA has allocated a CAtype code of XX for the extension CAtype. 470 [[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]] 472 6.2. End of Numeric CAtype Registration 474 No further registration of numeric CAtypes is permitted, and the 475 register created as part of [RFC4776] is cloased. New registrations 476 in this registry use the registration template in Section 6.5. 478 6.3. URN sub-namespace registration for 479 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' 481 This document calls for IANA to register a new XML namespace, as per 482 the guidelines in [RFC3688]. 484 URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 486 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 487 James Winterbottom (james.winterbottom@andrew.com). 489 XML: 491 BEGIN 492 493 495 496 497 GEOPRIV Civic Address Extensions 498 499 500

Additional Fields for GEOPRIV Civic Address

501

urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext

502 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 503 with the RFC number for this specification.]] 504

See RFCXXXX.

505 506 507 END 509 6.4. XML Schema Registration 511 This section registers an XML schema as per the procedures in 512 [RFC3688]. 514 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 516 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 517 James Winterbottom (james.Winterbottom@andrew.com). 519 The XML for this schema can be found as the entirety of 520 Section 4.5 of this document. 522 6.5. Registration Template 524 New registrations in the "CAtypes" registry require the following 525 information: 527 CAtype: The assigned numeric CAtype. All new registrations use the 528 value XX. [[IANA/RFC-Editor: update XX] Existing registrations 529 use their assigned value. 531 Namespace URI: A unique identifier for the XML namespace used for 532 the extension element. 534 Local Name: The local name of an XML element that carries the civic 535 address element. 537 Description: A brief description of the semantics of the civic 538 address element. 540 (Optional) Example: One or more simple examples of the element. 542 Contact: Contact details for the person providing the extension. 544 (Optional) Specification: A reference to a specification for the 545 civic address element. 547 (Optional) Schema: A reference to a formal schema (XML schema, 548 RelaxNG, or other form) that defines the extension. 550 Registrations from [RFC4776] and [RFC5139] are registered with the 551 following form: 553 CAtype: (The existing CAtype.) 555 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr 557 Local Name: (The contents of the PIDF column.) 559 Description: (The existing description for the element, including a 560 note about the equivalent NENA field, if present.) 562 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 563 (geopriv@ietf.org). 565 Specification: RFC4776 and RFC5139 567 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 569 Registration of the schema defined in this document in Section 4.5. 571 CAtype: The assigned numeric CAtype value is XX. [[IANA/RFC-Editor: 572 update XX] 574 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 575 Local Name: PN, MP, STP, HNP 577 Description: PN: Post number that is attributed to a lamp post or 578 utility pole. 580 Description: MP: Mile Post a marker indicating distance to or from a 581 place (often a town). 583 Description: STP: Street Type Prefix. 585 Description: HNP: House Number Prefix. 587 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 588 (geopriv@ietf.org). 590 Specification: RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC 591 URL and replace XXXX with the RFC number for this specification.]] 593 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 595 6.6. Registration Policy and Expert Guidance 597 The "CAtypes" registry is altered to operate on a registration policy 598 of "Expert Review", and optionally "Specification Required" 599 [RFC5226]. 601 The registration rules for "Specification Required" are followed only 602 if a registration includes a reference to a specification. 603 Registrations can be made without a specification reference. 605 All registrations are reviewed to identify potential duplication 606 between registered elements. Duplicated semantics are not prohibited 607 in the registry, though it is preferred if existing elements are 608 used. The expert review is advised to recommend the use of existing 609 elements following the guidance in [RFC5774]. Any registration that 610 is a duplicate or could be considered a close match for the semantics 611 of an existing element SHOULD include a discussion of the reasons 612 that the existing element was not reused. 614 7. Acknowledgements 616 Thanks to anyone who has tried to extend the civic schema and found 617 it a little unintuitive. 619 8. References 620 8.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 626 January 2004. 628 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 629 (DHCPv4 and DHCPv6) Option for Civic Addresses 630 Configuration Information", RFC 4776, November 2006. 632 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 633 Format for Presence Information Data Format Location 634 Object (PIDF-LO)", RFC 5139, February 2008. 636 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 637 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 638 May 2008. 640 [XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray, 641 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 642 Consortium Recommendation REC-xml-names11-20060816, 643 August 2006, 644 . 646 8.2. Informative References 648 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 649 10646", STD 63, RFC 3629, November 2003. 651 [RFC4079] Peterson, J., "A Presence Architecture for the 652 Distribution of GEOPRIV Location Objects", RFC 4079, 653 July 2005. 655 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 656 Emergency Context Resolution with Internet Technologies", 657 RFC 5012, January 2008. 659 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 660 Tschofenig, "LoST: A Location-to-Service Translation 661 Protocol", RFC 5222, August 2008. 663 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 664 Addresses in the Presence Information Data Format Location 665 Object (PIDF-LO): Guidelines and IANA Registry 666 Definition", BCP 154, RFC 5774, March 2010. 668 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 669 RFC 5985, September 2010. 671 Authors' Addresses 673 James Winterbottom 674 Andrew Corporation 675 Andrew Building (39) 676 Wollongong University Campus 677 Northfields Avenue 678 Wollongong, NSW 2522 679 AU 681 Phone: +61 242 212938 682 Email: james.winterbottom@andrew.com 684 Martin Thomson 685 Andrew Corporation 686 Andrew Building (39) 687 Wollongong University Campus 688 Northfields Avenue 689 Wollongong, NSW 2522 690 AU 692 Phone: +61 2 4221 2915 693 Email: martin.thomson@andrew.com 695 Richard Barnes 696 BBN Technologies 697 9861 Broken Land Parkway 698 Columbia, MD 21046 699 US 701 Phone: +1 410 290 6169 702 Email: rbarnes@bbn.com 704 Brian Rosen 705 NeuStar, Inc. 706 470 Conrad Dr 707 Mars, PA 16046 708 US 710 Email: br@brianrosen.net 711 Robins George 712 Huawei Technologies 713 Huawei Base, Bantian, Longgan District 714 Shenzhen, Guangdong 518129 715 P. R. China 717 Phone: +86 755 2878 8314 718 Email: robinsg@huawei.com