idnits 2.17.1
draft-thomson-geopriv-held-measurements-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1110.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1121.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1128.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1134.
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 :
----------------------------------------------------------------------------
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 23, 2007) is 6028 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)
== Missing Reference: '0-5' is mentioned on line 829, but not defined
== Missing Reference: '0-4' is mentioned on line 829, but not defined
== Missing Reference: '0-9' is mentioned on line 829, but not defined
== Missing Reference: '0-1' is mentioned on line 829, but not defined
** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
== Outdated reference: A later version (-16) exists of
draft-ietf-geopriv-http-location-delivery-02
== Outdated reference: A later version (-01) exists of
draft-winterbottom-geopriv-lis2lis-req-00
Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV M. Thomson
3 Internet-Draft J. Winterbottom
4 Intended status: Standards Track Andrew
5 Expires: April 25, 2008 October 23, 2007
7 Using Device-provided Location Measurements in HELD
8 draft-thomson-geopriv-held-measurements-00.txt
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on April 25, 2008.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2007).
39 Abstract
41 A method is described by which a Device is able to provide
42 measurement data to a LIS within a HELD request. Measurement
43 information are observations about the position of a Device, which
44 could be data about network attachment or about the physical
45 environment around the LIS. When a LIS generates location
46 information for a device, information from the device can improve the
47 accuracy of the location estimate. A basic set of measurements are
48 defined, including common modes of network attachment as well as
49 assisted Global Navigation Satellite System (GNSS) parameters.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
54 2. Conventions used in this document . . . . . . . . . . . . . . 4
55 3. Location Measurements in HELD Requests . . . . . . . . . . . . 5
56 4. Measurement Types . . . . . . . . . . . . . . . . . . . . . . 6
57 4.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 6
58 4.2. DHCP Measurements . . . . . . . . . . . . . . . . . . . . 7
59 4.3. 802.11 SSID Measurement . . . . . . . . . . . . . . . . . 7
60 4.4. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 7
61 4.4.1. GNSS System and Signal . . . . . . . . . . . . . . . . 9
62 4.4.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 10
63 4.4.3. Per-Satellite Measurements . . . . . . . . . . . . . . 10
64 4.5. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 11
65 4.5.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 11
66 4.5.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 12
67 4.5.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 12
68 4.5.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 13
69 5. Measurement Schema . . . . . . . . . . . . . . . . . . . . . . 14
70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
71 6.1. Expiry Time on Measurements . . . . . . . . . . . . . . . 21
72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
73 7.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 22
74 7.2. URN Sub-Namespace Registration for
75 urn:ietf:params:xml:ns:held:lm . . . . . . . . . . . . . . 23
76 7.3. XML Schema Registration for Measurement Schema . . . . . . 23
77 7.4. URN Sub-Namespace Registration for
78 urn:ietf:params:xml:ns:ip . . . . . . . . . . . . . . . . 24
79 7.5. XML Schema Registration for IP Address Type Schema . . . . 24
80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
82 8.2. Informative References . . . . . . . . . . . . . . . . . . 26
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
84 Intellectual Property and Copyright Statements . . . . . . . . . . 29
86 1. Introduction
88 HELD [I-D.ietf-geopriv-http-location-delivery] describes a means for
89 a device to request location information from an access network. The
90 LIS is expected to be able to retrieve the information necessary to
91 generate location information. As a part of the access network, the
92 LIS is able to acquire measurements from network devices within the
93 network to determine location information. The LIS also has access
94 to information about the network topology that can be used to turn
95 measurement data into location information. However, this
96 information can be enhanced with information acquired from the Device
97 itself.
99 This document describes a means for the Device to report location
100 measurements to the LIS. These measurements can be used by the LIS
101 to improve the quality of the location estimate it produces.
103 2. Conventions used in this document
105 The terms LIS and Device are used in this document in a manner
106 consistent with the usage in
107 [I-D.ietf-geopriv-http-location-delivery].
109 This document also uses the following definitions:
111 Location Measurement: An observation about the physical properties
112 of a particular device's network access. A location measurement
113 can be used to determine the location of a device; however,
114 location measurements do not identify a Device. Location
115 measurements can change with time if the location of the Device
116 also changes.
118 A location measurement does not necessarily contain location
119 information but it can be used in combination with contextual
120 knowledge of the network, or algorithms to derive location
121 information. Examples of location measurements: radio signal
122 strength or timing measurements, Ethernet switch and port
123 identifiers.
125 Location measurements can be considered sighting information,
126 based on the definition in [RFC3693].
128 Location Estimate: The result of location determination, a location
129 estimate is an approximation of where the Device is located.
130 Location estimates are subject to uncertainty, which arise from
131 measurement errors.
133 GNSS: Global Navigation Satellite System. A satellite-based system
134 that provides positioning and time information. For example, the
135 US Global Positioning System (GPS) or the European Galileo system.
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
139 document are to be interpreted as described in [RFC2119].
141 3. Location Measurements in HELD Requests
143 This document defines a standard container for the conveyance of
144 measurement parameters in HELD requests. This is an XML container
145 that identifies measurements by type and allows the Device to provide
146 any measurements it has.
148 The simplest example of measurement conveyance is illustrated by the
149 example message in Figure 1. This shows a HELD location request
150 message with an Ethernet switch and port measurement taken using LLDP
151 [IEEE.8021AB].
153
154 civic
155
156
157 0a01003c
158 c2
159
160
161
163 Figure 1: HELD Location Request with Measurement
165 Measurements that the LIS does not support or understand can be
166 ignored.
168 Multiple measurements, either of the same type or from different
169 sources can be included in the "measurements" element. The
170 "measurements" element SHOULD NOT be repeated.
172 The LIS SHOULD validate any location information derived based on
173 Device-provided measurements. Any measurements that produce location
174 information that is significantly different to location information
175 that the LIS is able to generate independently SHOULD be discarded.
176 The allowable degree of difference is left to local configuration or
177 implementation.
179 Using measurements is at the discretion of the LIS, but the "method"
180 parameter in the PIDF-LO SHOULD be adjusted reflect the method used.
182 4. Measurement Types
184 This document defines measurements for a range of common network
185 types.
187 Note: Not all of these measurement types are provided by the Device;
188 they may be acquired by other hosts in situations such as those
189 described in [I-D.winterbottom-geopriv-lis2lis-req].
191 4.1. LLDP Measurements
193 LLDP messages are sent between adjacent nodes in an 802.x network
194 (e.g. wired Ethernet, WiFi, WiMAX). These messages all contain
195 identification information for the sending node, which can be used to
196 determine location information. A Device that receives LLDP messages
197 can report this information as a measurement to the LIS, which is
198 then able to use the measurement in determining the location of the
199 Device.
201 The Device MUST report the values directly as they were provided by
202 the adjacent node. Attempting to adjust the type of identifier is
203 likely to cause the measurement to be useless.
205 Where a Device has received LLDP messages from multiple adjacent
206 nodes, it should provide information extracted from those messages by
207 repeating the "lldp" element.
209 An example of an LLDP measurement is shown in Figure 2. This shows
210 an adjacent node (chassis) that is identified by the IP address
211 192.0.2.45 and the port on that node is numbered using an agent
212 circuit ID [RFC3046] of 162.
214
215
216 c000022d
217 a2
218
219
221 Figure 2: LLDP Measurement Example
223 802.x Devices that are able to obtain information about adjacent
224 network switches and their attachment to them by other means may use
225 this data type to convey this information.
227 4.2. DHCP Measurements
229 The DHCP Relay Agent Information option [RFC3046] provides
230 measurement information about a Device. This measurement information
231 can be included in the "dhcp-rai" element.
233 The elements in the DHCP relay agent information options are opaque
234 data types assigned by the DHCP relay agent. The three items are all
235 optional: circuit identifier ("circuit", [RFC3046]), remote
236 identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier
237 ("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier
238 has an associated enterprise number [IANA.enterprise] as an XML
239 attribute.
241
242
243 2001:DB8::215:c5ff:fee1:505e
244 108b
245
246
248 Figure 3: DHCP Relay Agent Information Measurement Example
250 4.3. 802.11 SSID Measurement
252 In WiFi, or 802.11, networks a Device might be able to provide the
253 service set identifier (SSID) of the wireless network that it is
254 attached to. This is provided using the "ssid" element, as shown in
255 Figure 4.
257
258 wlan-home
259
261 Figure 4: 802.11 SSID Measurement Example
263 4.4. GNSS Measurements
265 GNSS use orbiting satellites to transmit signals. A Device with a
266 GNSS receiver is able to take measurements from the satellite
267 signals. These measurements can be used to determine time and the
268 location of the Device.
270 Determining location and time in autonomous GNSS receivers follows
271 three steps:
273 Signal acquisition: During the signal acquisition stage, the
274 receiver searches for the repeating code that is sent by each GNSS
275 satellite. Successful operation typically requires measurements
276 for a minimum of 5 satellites. At this stage, measurement
277 information is available to the device.
279 Navigation message decode: Once the signal has been acquired, the
280 receiver then receives information about the configuration of the
281 satellite constellation. This information is broadcast by each
282 satellite and is modulated with the base signal at a low rate; for
283 instance, GPS sends this information at about 50 bits per second.
285 Calculation: The measurement information is combined with the data
286 on the satellite constellation to determine the location of the
287 receiver and the current time.
289 A Device that uses a GNSS receiver is able to report measurements
290 after the first stage of this process. A LIS can use these
291 measurements to determine a location. In the case where there are
292 fewer measurements available than the optimal minimum, the LIS might
293 be able to use other sources of measurement information and combine
294 the measurements to determine a position.
296 Note: The use of different sets of GNSS _assistance data_ can
297 reduce the amount of time required for the signal acquisition
298 stage and obviate the need for the receiver to extract data on the
299 satellite constellation. Provision of assistance data is outside
300 the scope of this document.
302 Figure 5 shows an example GNSS measurement. The measurement shown is
303 for the GPS system and includes measurements for three satellites
304 only.
306
307
308
309
310 499.93950.87595747
311 450.5
312
313
314 378.26570.56639479
315 520.5
316
317
318 -633.03090.57016835
319 480.5
320
321
322
324 Figure 5: Example GNSS Measurement
326 Each "gnss" element represents a single set of GNSS measurement data,
327 taken at a single point in time. Measurements taken at different
328 times can be included in different "gnss" elements to enable
329 iterative refinement of results.
331 GNSS measurement parameters are described in more detail in the
332 following sections.
334 4.4.1. GNSS System and Signal
336 The GNSS measurement structure is designed to be generic and to apply
337 to different GNSS types. Different signals within those systems are
338 also accounted for and can be measured separately.
340 The GNSS type determines the time system that is used. An indication
341 of the type of system and signal can ensure that the LIS is able to
342 correctly use measurements.
344 Measurements for multiple GNSS types and signals can be included by
345 repeating the "gnss" element.
347 This document creates an IANA registry for GNSS types. Two satellite
348 systems are registered by this document: GPS and Galileo. Details
349 for the registry are included in Section 7.1.
351 4.4.2. Time
353 Each set of GNSS measurements is taken at a specific point in time.
354 The "time" element includes a relative time in milliseconds using the
355 time system native to the satellite system.
357 For the GPS satellite system, the "time" element includes the time of
358 week in milliseconds. For the Galileo system, the "time" element
359 includes the time of day in milliseconds.
361 Alternatively, a specific instant of time can be specified using the
362 "abstime" element. This element includes an ISO 8601 formatted date
363 and time, which SHOULD be measured to within one millisecond.
365 4.4.3. Per-Satellite Measurements
367 Multiple satellites are included in each set of GNSS measurements
368 using the "sat" element. Each satellite is identified by a number in
369 the "num" attribute. The satellite number is consistent with the
370 identifier used in the given GNSS.
372 Both the GPS and Galileo systems use satellite numbers between 1 and
373 64.
375 The GNSS receiver measures the following parameters for each
376 satellite:
378 doppler: The observed Doppler shift of the satellite signal,
379 measured in meters per second. This is converted from a value in
380 Hertz.
382 codephase: The observed code phase for the satellite signal,
383 measured in milliseconds. This is converted from a value in chips
384 or wavelengths. Increasing values indicate increasing
385 pseudoranges.
387 cn0: The signal to noise ratio for the satellite signal, measured in
388 decibel-Hertz (dB-Hz). The expected range is between 20 and 50
389 dB-Hz.
391 err: The estimated RMS error for the code phase measurement; i.e. an
392 estimate of code phase uncertainty. This value is measured in
393 meters.
395 mp: An estimation of the amount of error that multipath signals
396 contribute in meters. This measurement parameter is optional.
398 cq: An indication of the carrier quality. Two attributes are
399 included: "continuous" may be either "true" or "false"; direct may
400 be either "direct" or "inverted". This measurement parameter is
401 optional.
403 adr: The accumulated Doppler range, measured in meters. This
404 measurement parameter is optional and should not be included
405 unless multiple sets of GNSS measurements are provided.
407 All values are converted from measures native to the satellite system
408 to generic measures to ensure consistency of interpretation. Unless
409 necessary, the schema does not constrain these values.
411 4.5. DSL Measurements
413 Digital Subscriber Line (DSL) networks rely on a range of network
414 technology. DSL deployments regularly require cooperation between
415 multiple organizations. These fall into two broad categories:
416 infrastructure providers and Internet service providers (ISPs).
417 Infrastructure providers manage the bulk of the physical
418 infrastructure including cabling. End users obtain their service
419 from an ISP, which manages all aspects visible to the end user
420 including IP address allocation and operation of a LIS. See
421 [DSL.TR025] and [DSL.TR101] for further information on DSL network
422 deployments.
424 Exchange of measurement information between these organizations is
425 necessary for location information to be correctly generated. The
426 ISP LIS needs to acquire location information from the infrastructure
427 provider. However, the infrastructure provider has no knowledge of
428 Device identifiers, it can only identify a stream of data that is
429 sent to the ISP. This is resolved by passing measurement information
430 relating to the Device to a LIS operated by the infrastructure
431 provider.
433 4.5.1. L2TP Measurements
435 Layer 2 Tunneling Protocol (L2TP) is a common means of linking the
436 infrastructure provider and the ISP. The infrastructure provider LIS
437 requires a measurement that identifies a single L2TP tunnel, from
438 which it can generate location information. Figure 6 shows an
439 example L2TP measurement.
441
442
443
444 192.0.2.10
445 192.0.2.61
446 528
447
448
449
451 Figure 6: Example DSL L2TP Measurement
453 4.5.2. RADIUS Measurements
455 When authenticating network access, the infrastructure provider might
456 employ RADIUS [RFC2865] proxying at the DSL Access Module (DSLAM) or
457 Access Node (AN). These messages provide the ISP RADIUS server with
458 an identifier for the DSLAM or AN, plus the slot and port that the
459 Device is attached on. These data can be provided as a measurement,
460 which allows the infrastructure provider LIS to generate location
461 information.
463 The format of the AN, slot and port identifiers are not defined in
464 the RADIUS protocol. Slot and port together identify a circuit on
465 the AN, analagous to the circuit identifier in [RFC3046]. These
466 items are provided directly, as they were in the RADIUS message. An
467 example is shown in Figure 7.
469
470
471 AN-7692
472 3
473 06
474
475
477 Figure 7: Example DSL RADIUS Measurement
479 4.5.3. Ethernet VLAN Tag Measurements
481 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM)
482 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is
483 used to identify the incoming residential circuit, while the S-TAG is
484 used to identify the DSLAM or AN. The C-TAG and S-TAG together can
485 be used to identify a single point of network attachment. An example
486 is shown in Figure 8.
488
489
490 613
491 1097
492
493
495 Figure 8: Example DSL VLAN Tag Measurement
497 Alternatively, the C-TAG can be replaced by data on the slot and port
498 that the Device is attached to. This information might be included
499 in RADIUS requests that are proxied from the infrastructure provider
500 to the ISP RADIUS server.
502 4.5.4. ATM Virtual Circuit Measurements
504 An ATM virtual circuit can be employed between the ISP and
505 infrastructure provider. Providing the virtual port ID (VPI) and
506 virtual circuit ID (VCI) for the virtual circuit gives the
507 infrastructure provider LIS the ability to identify a single data
508 stream. A sample measurement is shown in Figure 9.
510
511
512 55
513 6323
514
515
517 Figure 9: Example DSL ATM Measurement
519 5. Measurement Schema
521 Note that the pattern rules in the following schema wrap due to
522 length constraints in RFC. None of the patterns contain whitespace.
524
525
532
533
535 HELD Capabilities
536
537
538
540 This schema defines a framework for location measurements
541 in HELD and several measurement formats.
542
543
545
546
547
548
549
550
551
552
553
554
555
557
558
559
560
561
562
564
565
566
567
568
569
570
571
572
574
575
576
577
578
580
581
582
583
585
586
587
589
590
591
592
593
594
596
597
598
599
600
601
602
603
605
607
609
611
612
613
614
616
618
619
620
621
623
624
625
627
628
629
630
631
632
633
635
636
637
638
639
640
641
643
644
645
646
647
648
649
650
651
653
655
656
657
658
659
660
661
663
664
665
666
667
668
669
670
671
673
675
676
677
679
680
681
683
684
685
686
688
689
690
691
692
693
694
695
696
697
698
700
701
702
703
704
705
706
707
708
709
710
711
712
713
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
757
758
759
760
761
762
763
764
765
766
767
768
769
771
772
773
774
775
777
778
779
781
782
783
784
785 An IP version 6 address, based on RFC 4291.
786
787
788
789
790
791
792
793
794
796
798
800
802
804
806
807
808
809
818
819
820
821
823
824
825
826
830
831
832
834 6. Security Considerations
836 Location measurements are provided by the Device for the sole purpose
837 of generating more accurate location information. The LIS SHOULD NOT
838 retain location measurements for any longer than is necessary to
839 generate location information.
841 A LIS MUST NOT reveal location measurements to any other entity
842 unless given explicit permission by the Device. This document does
843 not include any means to indicate such permission.
845 6.1. Expiry Time on Measurements
847 A Device is able to indicate a time in the location measurement using
848 the "expires" attribute. Nominally, this attribute indicates how
849 long information is expected to be valid for, but a Device MAY use
850 this attribute to prevent the LIS from retaining measurement data.
852 The LIS MUST NOT keep location measurements beyond the time indicated
853 in the "expires" attribute. Where the "expires" attribute is not
854 provided, the LIS MUST discard location measurements immediately
855 after servicing the current request.
857 7. IANA Considerations
859 This section creates a registry for GNSS types (Section 4.4) and
860 registers the schema from Section 5.
862 7.1. IANA Registry for GNSS Types
864 This document establishes a new IANA registry for Global Navigation
865 Satellite System (GNSS) types. The registry includes tokens for the
866 GNSS type and for each of the signals within that type. Referring to
867 [RFC2434], this registry operates under both "Expert Review" and
868 "Specification Required" rules. The IESG will appoint an Expert
869 Reviewer who will advise IANA promptly on each request for a new or
870 updated GNSS type.
872 Each entry in the registry requires the following information:
874 GNSS name: the name and a brief description of the GNSS
876 Brief description: the name and a brief description of the GNSS
878 GNSS token: a token that can be used to identify the GNSS
880 Signals: a set of tokens that represent each of the signals that the
881 system provides
883 Documentation reference: a reference to a stable, public
884 specification that outlines usage of the GNSS, including (but not
885 limited to) signal specifications and time systems; additionally
886 assistance data formats and supporting protocols can be specified
888 The registry initially includes two registrations:
890 GNSS name: Global Positioning System (GPS)
892 Brief description: a system of satellites that use spread-spectrum
893 transmission, operated by the US military for commercial and
894 military applications
896 GNSS token: gps
898 Signals: L1, L2, L1C, L2C, L5
900 Documentation reference: Navstar GPS Space Segment/Navigation User
901 Interface [GPS.ICD]
903 GNSS name: Galileo
905 Brief description: a system of satellites that operate in the same
906 spectrum as GPS, operated by the European Union for commercial
907 applications
909 GNSS Token: galileo
911 Signals: L1, E5A, E5B, E5A+B, E6
913 Documentation Reference: Galileo Open Service Signal In Space
914 Interface Control Document (SIS ICD) [Galileo.ICD]
916 7.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm
918 This section registers a new XML namespace,
919 "urn:ietf:params:xml:ns:held:lm", as per the guidelines in [RFC3688].
921 URI: urn:ietf:params:xml:ns:held:lm
923 Registrant Contact: IETF, GEOPRIV working group,
924 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
926 XML:
928 BEGIN
929
930
932
933
934 HELD Measurements
935
936
937
Namespace for HELD Measurements
938
urn:ietf:params:xml:ns:held:lm
939 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
940 with the RFC number for this specification.]]
941
942
943
944 END
946 7.3. XML Schema Registration for Measurement Schema
948 This section registers an XML schema as per the guidelines in
949 [RFC3688].
951 URI: urn:ietf:params:xml:schema:held:lm
953 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
954 Martin Thomson (martin.thomson@andrew.com).
956 Schema: The XML for this schema can be found in Section 5 of this
957 document.
959 7.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:ip
961 This section registers a new XML namespace,
962 "urn:ietf:params:xml:ns:ip", as per the guidelines in [RFC3688].
964 URI: urn:ietf:params:xml:ns:ip
966 Registrant Contact: IETF, GEOPRIV working group,
967 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
969 XML:
971 BEGIN
972
973
975
976
977 IP Address Types
978
979
980
Namespace for IP Address Types
981
urn:ietf:params:xml:ns:ip
982 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
983 with the RFC number for this specification.]]
984
985
986
987 END
989 7.5. XML Schema Registration for IP Address Type Schema
991 This section registers an XML schema as per the guidelines in
992 [RFC3688].
994 URI: urn:ietf:params:xml:schema:ip
995 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
996 Martin Thomson (martin.thomson@andrew.com).
998 Schema: The XML for this schema can be found in Section 5 of this
999 document.
1001 8. References
1003 8.1. Normative References
1005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1006 Requirement Levels", BCP 14, RFC 2119, March 1997.
1008 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1009 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
1010 October 1998.
1012 [I-D.ietf-geopriv-http-location-delivery]
1013 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
1014 "HTTP Enabled Location Delivery (HELD)",
1015 draft-ietf-geopriv-http-location-delivery-02 (work in
1016 progress), September 2007.
1018 8.2. Informative References
1020 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
1021 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
1023 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
1024 RFC 3046, January 2001.
1026 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
1027 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
1028 August 2006.
1030 [IANA.enterprise]
1031 IANA, "Private Enterprise Numbers",
1032 .
1034 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
1035 Suboption for the Dynamic Host Configuration Protocol
1036 (DHCP) Relay Agent Option", RFC 3993, March 2005.
1038 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
1039 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
1040 June 2006.
1042 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1043 January 2004.
1045 [IEEE.8021AB]
1046 IEEE, "IEEE Standard for Local and Metropolitan area
1047 networks, Station and Media Access Control Connectivity
1048 Discovery", 802.1AB, June 2005.
1050 [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface",
1051 ICD GPS-200, Apr 2000.
1053 [Galileo.ICD]
1054 GJU, "Galileo Open Service Signal In Space Interface
1055 Control Document (SIS ICD)", May 2006.
1057 [I-D.winterbottom-geopriv-lis2lis-req]
1058 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
1059 Requirements", draft-winterbottom-geopriv-lis2lis-req-00
1060 (work in progress), June 2007.
1062 [DSL.TR025]
1063 Wang, R., "Core Network Architecture Recommendations for
1064 Access to Legacy Data Networks over ADSL", September 1999.
1066 [DSL.TR101]
1067 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSl
1068 Aggregation", April 2006.
1070 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1071 "Remote Authentication Dial In User Service (RADIUS)",
1072 RFC 2865, June 2000.
1074 Authors' Addresses
1076 Martin Thomson
1077 Andrew
1078 PO Box U40
1079 Wollongong University Campus, NSW 2500
1080 AU
1082 Phone: +61 2 4221 2915
1083 Email: martin.thomson@andrew.com
1084 URI: http://www.andrew.com/
1086 James Winterbottom
1087 Andrew
1088 PO Box U40
1089 Wollongong University Campus, NSW 2500
1090 AU
1092 Phone: +61 2 4221 2938
1093 Email: james.winterbottom@andrew.com
1094 URI: http://www.andrew.com/
1096 Full Copyright Statement
1098 Copyright (C) The IETF Trust (2007).
1100 This document is subject to the rights, licenses and restrictions
1101 contained in BCP 78, and except as set forth therein, the authors
1102 retain all their rights.
1104 This document and the information contained herein are provided on an
1105 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1106 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1107 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1108 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1109 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1110 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1112 Intellectual Property
1114 The IETF takes no position regarding the validity or scope of any
1115 Intellectual Property Rights or other rights that might be claimed to
1116 pertain to the implementation or use of the technology described in
1117 this document or the extent to which any license under such rights
1118 might or might not be available; nor does it represent that it has
1119 made any independent effort to identify any such rights. Information
1120 on the procedures with respect to rights in RFC documents can be
1121 found in BCP 78 and BCP 79.
1123 Copies of IPR disclosures made to the IETF Secretariat and any
1124 assurances of licenses to be made available, or the result of an
1125 attempt made to obtain a general license or permission for the use of
1126 such proprietary rights by implementers or users of this
1127 specification can be obtained from the IETF on-line IPR repository at
1128 http://www.ietf.org/ipr.
1130 The IETF invites any interested party to bring to its attention any
1131 copyrights, patents or patent applications, or other proprietary
1132 rights that may cover technology that may be required to implement
1133 this standard. Please address the information to the IETF at
1134 ietf-ipr@ietf.org.
1136 Acknowledgment
1138 Funding for the RFC Editor function is provided by the IETF
1139 Administrative Support Activity (IASA).