One document matched: draft-polk-geopriv-3825-update-00.txt
Geopriv WG James Polk
Internet-Draft Marc Linsner
Expires: October 23, 2009 Allan Thomson
Intended Status: Standards Track (PS) Cisco Systems
Updates: RFC 3825 (if published) April 23, 2009
An Update to the Dynamic Host Configuration Protocol Option
for Coordinate-based Location Configuration Information
draft-polk-geopriv-3825-update-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 23, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Abstract
This document updates RFC 3825 (Dynamic Host Configuration Protocol
Option for Coordinate-based Location Configuration Information) to
allow versioning, and proposes changes that enable the ability to
express confidence and uncertainty values as an alternative to
expressing bits of resolution.
Polk, et al. Expires October 23, 2009 [Page 1]
Internet-Draft DHCP Geo Option Update April 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Versioning in DHCP Option . . . . . . . . . . . . . . . . . . 3
3. Replacing Resolution Fields with Confidence and Uncertainty . 4
4. What to do with RFC 3825's Appendix . . . . . . . . . . . . . 5
5. Security considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 5
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
1. Introduction
Rough consensus from the community has motivated this document to
propose an update RFC 3825 (Dynamic Host Configuration Protocol
Option for Coordinate-based Location Configuration Information) to
account for versioning. The reason for this is the feeling that the
resolution bits are better served expressing other data, such as
confidence and uncertainty.
The DHCP Option (123) in RFC 3825 [RFC3825] is only 17 bytes in
length, and there are no reserved bits to assign, therefore anything
added needs to take bits - or entire fields - from something already
assigned in the existing Option.
This proposal borrows an idea from [ID-3825bis] of reassigning the
resolution fields into confidence and uncertainty fields.
The most obvious place to steal bits from outside of the resolution
bits is from the 8 bit datum field. Currently, there are 3 datums
IANA registered. It is foreseen that few others will be necessary.
Therefore, this appears to be a logical place to steal bits. At
issue is the number of bits to be used for this purpose.
In an effort to accommodate other specifications that utilize the
Option defined by RFC3825, these additions do not force changes to
those specifications. Specifically, IEEE 802.11k and 802.11y refer
to RFC3825. To ensure compatibility with those specifications and
the original RFC3825, we have to look for what can accommodate each
specification.
Polk, et al. Expires October 23, 2009 [Page 2]
Internet-Draft DHCP Geo Option Update April 2009
While 802.11k has not changed the datum field from that in RFC 3825,
802.11y has. 802.11y, in 2008, reduced the number of datum bits from
8 to 3 bits [IEEE.11y], shown here:
0 7 0 3 4 5 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Datum | ---> |Datum|1|2|3|res|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Datum field in Five new fields in .11y
RFC 3825 from that in RFC 3825
802.11y have additionally assigned the middle 3 bits as individual
flags, and have left the 2 most significant bits (MSB) as
"reserved". In an effort to provide harmony, this proposal
specifically does not make use of the bits reassigned in the IEEE
specification. Future revisions of this specification may be in
conflict with the IEEE specification and will be re-evaluated at
that time. So, supporting the IEEE, this specification utilizes the
2 MSB to declare a version value. This leaves 4 possible versions,
where version 1 is defined by RFC 3825. Version 2 is defined here.
Section 2 of this document discusses versioning in more detail.
Section 3 discusses how the resolution bits are reassigned into
confidence and uncertainty fields in version 2 (RFC 3825 is to be
considered version 1). Section 4 discusses what to do with RFC
3825's appendix in this and subsequent versions of Option 123.
2. Versioning in DHCP Option 123
This proposal concludes the best bits to steal are from the existing
8 bit datum field, the described in RFC 3825 Option format.
This document proposes the IETF adopt conformance with the IEEE in
this case by only having the ability to have 4 versions of Option
123, from the 2 MSB (on the left). This would look like this:
0 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Datum | ---> |Datum| res |ver|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Datum field in field split into 3
RFC 3825 separate field in
This preserves compliance with existing .11y implementations and
definitions, and yields the DHCP the ability to have 4 versions of
this Option.
The middle 3 bits (specifically bits 3, 4 and 5) are proposed to be
newly classified as "reserved". This aligns with 802.11y, and allows
Polk, et al. Expires October 23, 2009 [Page 3]
Internet-Draft DHCP Geo Option Update April 2009
the IETF and IEEE to work out how to encroach into this space in the
future for, perhaps, more datum space, or more versioning space, or
something entirely different.
[Editor's note: These 3 reserved bits are not set as mandatory
within this proposal.]
2.1 Backwards Compatibility with Option 123 Version 1
Version 2 and later implementations will remain backwards compatible
as long as they use each field assigned in RFC 3825 as is described
in that document. If a version 1 client uses a datum not defined
within RFC 3825, it will not parse the content properly. To date, no
new datums have been assigned to the IANA registry for this datum
field, therefore this has always been the case. This likely will
cause an error by the client.
Version 1 implementations that receive a version 2 Option, for
example with WGS84 as the datum, will not receive the expected field
value of 1, shown here:
0 7
+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
Version 1
but that of 65, shown here:
0 7
+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+
Version 2
3. Replacing Resolution Fields with Confidence and Uncertainty
It is best at this point to merely review what is written in
[ID-3825bis] for the specifics on what could go here.
[Editor's note: we authors do not have permission, based on RFC 5378,
to copy the text from [ID-3825bis] at this time. That
text is probably the best available to suit this
section, and we want to avoid attempting to rewrite
that text.]
4. What to do with RFC 3825's Appendix
In version 2 and later of Option 123, readers SHOULD simply ignore
Polk, et al. Expires October 23, 2009 [Page 4]
Internet-Draft DHCP Geo Option Update April 2009
the appendix from RFC 3825. Without the resolution fields, that
appendix serves no purpose.
5. Security considerations
There are no additional security considerations outside those
written in RFC 3825.
6. IANA considerations
This document does not have any IANA actions (at this time).
7. Acknowledgments
Your name here... or if you contribute a fair amount of text, you
can be a co-author.
8. References
8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[ID-3825bis] M. Thomson, J. Winterbottom, "Dynamic Host Configuration
Protocol Option for Geodetic Location Information", "work in
progress", Jan 2009
[IEEE.11y] IEEE Std 802.11y, March 2008
8.2. Informative References
none
Authors' Addresses
James Polk
3913 Treemont Circle
Colleyville, Texas, USA
+1.817.271.3552
mailto: jmpolk@cisco.com
Polk, et al. Expires October 23, 2009 [Page 5]
Internet-Draft DHCP Geo Option Update April 2009
Allan Thomson
Cisco Systems, Inc.
San Jose, California, USA
Email: althomso@cisco.com
Marc Linsner
Cisco Systems, Inc.
Marco Island, Florida, USA
Email: mlinsner@cisco.com
Polk, et al. Expires October 23, 2009 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-22 23:10:33 |