idnits 2.17.1 draft-polk-geopriv-dhc-geo-lci-upstream-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 180. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 157. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 170. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC3825, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 25 has weird spacing: '... at any time....' == Line 26 has weird spacing: '...ference mater...' == Line 154 has weird spacing: '... rights might...' == Line 155 has weird spacing: '... it has made ...' == Line 156 has weird spacing: '...rmation on th...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3046' is defined on line 121, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 127, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group James M. Polk 3 Internet-Draft Ralph Droms 4 Expires: November 11th, 2005 Cisco Systems 5 May 11th, 2005 7 Dynamic Host Configuration Protocol (DHCP) Location 8 Configuration Information Transmitted Upstream 9 draft-polk-geopriv-dhc-geo-lci-upstream-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 29, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document updates RFC 3825 to allow explicitly the transmission 44 of DHCP option 123, "Location Configuration Information", from a 45 DHCP client to a DHCP server. Transmission of option 123 from a 46 client to a server allows a client that knows its location through 47 some other means to communicate that location to the DHCP server. 49 1. Introduction 51 This document updates RFC 3825, "Dynamic Host Configuration Protocol 52 Option for Coordinate-based Location Configuration Information" 53 [RFC3825], to allow explicitly the transmission of DHCP option 123, 54 "Location Configuration Information", from the client to the server. 56 This document updates RFC 3825 [RFC3825]. 58 1.1 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 2. Transmitting DHCP Option 123 Upstream 66 RFC3825 made communications between the client and server explicit 67 for retrieval of location configuration information (in the 68 coordinate format), but only explicitly discussed location 69 information going from the server to the client. This option can be 70 supplied to the client unrequested, or it can be requested by the 71 client. See RFC 3825 for those details. 73 In addition to the case in which the DHCP server explicitly provides 74 location information to the client, it may be the case that the 75 client has obtained its own location information through some other 76 mechanism such as manual configuration or through a Global 77 Positioning System (GPS). When the client has its own location 78 information, the client MAY include that information in DHCP option 79 123 [RFC3825] in a DHCPDISCOVER or DHCPREQUEST message sent to the 80 server, to supply the client's location information to the DHCP 81 server. 83 3. IANA Considerations 85 This document makes no request of the IANA. 87 Note to RFC Editor: in the process assigning numbers and building 88 IANA registries prior to publication, this section will have served 89 its purpose. It may therefore be removed upon publication as an 90 RFC. 92 4. Security Considerations 94 Where critical decisions might be based on the value of this LCI 95 option, DHCP authentication in [RFC3118] SHOULD be used to protect 96 the integrity of the DHCP options. 98 Since there is no privacy protection for DHCP messages, an 99 eavesdropper who can monitor the link between the client and 100 destination DHCP server to capture this LCI. 102 When implementing a DHC server that will serve clients across an 103 uncontrolled network, one should consider the potential security 104 risks. 106 5. Acknowledgements 108 To Ted Hardie for comments leading to this document's creation. 110 6. References 112 6.1 Normative References 114 [RFC3825] Polk, J., Schnizlein, J., Linsner, M., " Dynamic Host 115 Configuration Protocol Option for Coordinate-based 116 Location Configuration Information", RFC 3825, July 2004 118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 119 Requirement Levels", BCP 14, RFC 2119, March 1997. 121 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 122 3046, January 2001. 124 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 125 Messages", RFC 3118, June 2001. 127 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 128 2131, March 1997. 130 Author's Address 132 James M. Polk 133 Cisco Systems 134 3913 Treemont Circle 135 Colleyville, Texas 76034 136 USA 138 Phone: +1-817-271-3552 139 Email: jmpolk@cisco.com 141 Ralph Droms 142 Cisco Systems 143 1414 Massachusetts Avenue 144 Boxborough, MA 01719 145 Phone: +1-978-936-1674 146 Email: rdroms@cisco.com 148 Intellectual Property Statement 150 The IETF takes no position regarding the validity or scope of any 151 Intellectual Property Rights or other rights that might be claimed 152 to pertain to the implementation or use of the technology described 153 in this document or the extent to which any license under such 154 rights might or might not be available; nor does it represent that 155 it has made any independent effort to identify any such rights. 156 Information on the procedures with respect to rights in RFC 157 documents can be found in BCP 78 and BCP 79. 159 Copies of IPR disclosures made to the IETF Secretariat and any 160 assurances of licenses to be made available, or the result of an 161 attempt made to obtain a general license or permission for the use 162 of such proprietary rights by implementers or users of this 163 specification can be obtained from the IETF on-line IPR repository 164 at http://www.ietf.org/ipr. 166 The IETF invites any interested party to bring to its attention any 167 copyrights, patents or patent applications, or other proprietary 168 rights that may cover technology that may be required to implement 169 this standard. Please address the information to the IETF at 170 ietf-ipr@ietf.org. 172 Disclaimer of Validity 174 This document and the information contained herein are provided on 175 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 176 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 177 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 178 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 179 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 180 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 182 Copyright Statement 184 Copyright (C) The Internet Society (2005). This document is subject 185 to the rights, licenses and restrictions contained in BCP 78, and 186 except as set forth therein, the authors retain all their rights. 188 Acknowledgment 190 Funding for the RFC Editor function is currently provided by the 191 Internet Society.