1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
|
<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-gellens-lost-validation-09" indexInclude="true" ipr="trust200902" number="8917" prepTime="2020-10-22T13:57:24" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="2" tocInclude="true" updates="5222" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-gellens-lost-validation-09" rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8917" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<front>
<title abbrev="LoST-Validation">The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag</title>
<seriesInfo name="RFC" value="8917" stream="IETF"/>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization showOnFrontPage="true">Core Technology Consulting</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>United States of America</country>
</postal>
<email>rg+ietf@coretechnologyconsulting.com</email>
<uri>http://www.coretechnologyconsulting.com</uri>
</address>
</author>
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization showOnFrontPage="true"/>
<address>
<postal>
<street>470 Conrad Dr.</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>United States of America</country>
</postal>
<phone></phone>
<email>br@brianrosen.net</email>
</address>
</author>
<date month="10" year="2020"/>
<area>Real-Time Applications and Infrastructure</area>
<keyword>location</keyword>
<keyword>LoST</keyword>
<keyword>emergency</keyword>
<keyword>emergency services</keyword>
<keyword>ecrf</keyword>
<keyword>lvf</keyword>
<keyword>i3</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">This document adds the 'LoST-Validation' service tag to the
Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service
Tag IANA registry. This tag can appear in a Naming Authority Pointer
(NAPTR) Domain Name System (DNS) record to assist clients of the
Location-to-Service Translation (LoST) Protocol in identifying LoST
servers designated for location validation. This tag and
the information about its use update RFC 5222, which enables the explicit discovery of a server that supports location validation.</t>
</abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8917" brackets="none"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-document-scope">Document Scope</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-the-lost-validation-applica">The LoST-Validation Application Service Tag</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-backwards-compatibility">Backwards Compatibility</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-s-naptr-registration">S-NAPTR Registration</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="scope" numbered="true" toc="include" removeInRFC="false" pn="section-1">
<name slugifiedName="name-document-scope">Document Scope</name>
<t indent="0" pn="section-1-1">This document adds 'LoST-Validation' to the S-NAPTR Application
Service Tag IANA registry and describes how this tag fits in the LoST
server discovery procedure described in <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/>. This tag is used with Naming Authority Pointer
(NAPTR) Domain Name System (DNS) records so that clients of the
Location-to-Service Translation (LoST) Protocol <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/> can identify servers designated for location validation. This tag and the information on its use is an update to <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/> that enables the explicit discovery of a server that supports location validation.</t>
</section>
<section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-2">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-2-1">The LoST Protocol <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/> defines a mapping service with the
additional ability for a client to request that a civic address be
validated. The LoST protocol allows servers to ignore a request to
perform location validation. The National Emergency Number Association
(NENA) has defined an architecture for all-IP emergency services (known
as "i3" <xref target="NENA-i3" format="default" sectionFormat="of" derivedContent="NENA-i3"/>), which defines the
mapping (routing) and validation functions as two distinct functional
elements, defined as an Emergency Call Routing Function (ECRF) and a
Location Validation Function (LVF). NENA i3 requires that the mapping
(ECRF) and validation (LVF) functions be separable; an entity
responsible for a LoST server cluster can decide to provide mapping and
validation services using consolidated or separate server clusters
(i.e., using the same or separate boxes). The rationale is that the
mapping service is used in real time during emergency call routing,
while the validation service is used in advance, typically when data is
provisioned; therefore, the mapping service has much higher availability
and response-time requirements than the validation service. An
organization might choose to deploy these services using different
server clusters to make it easier to provide higher levels of service
for the mapping function while shielding it from the potentially bursty
load of validation. Another organization might choose to use the same
sets of servers for both services, configured and deployed to offer the high service level demanded of the mapping service.</t>
<t indent="0" pn="section-2-2">In order to permit this separability, any entity querying a LoST
server needs to be able to resolve an Application Unique String (AUS)
into a URL for a LoST server designated for the required service (mapping
or validation). This separability needs to be maintained throughout the
LoST tree structure, from forest guide to leaf node (LoST architecture
is described in <xref target="RFC5582" format="default" sectionFormat="of" derivedContent="RFC5582"/>). Because
LoST referrals return an AUS rather than a URL, either a different
service tag or a DNS name convention (e.g., "ecrf.example.org" and
"lvf.example.org") is needed to differentiate between the services. DNS name conventions are inflexible and fragile, making a different service tag the preferred approach.</t>
<t indent="0" pn="section-2-3">Because LoST servers may ignore a request to perform location
validation, a service tag explicitly for location validation also
reduces the likelihood (which has existed since <xref target="RFC5582" format="default" sectionFormat="of" derivedContent="RFC5582"/>) that a client needing location validation will reach servers that are not doing so
(due to configuration and/or conditions).</t>
<section anchor="req" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
<name slugifiedName="name-requirements-language">Requirements Language</name>
<t indent="0" pn="section-2.1-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
</section>
<section anchor="LoST-Validation" numbered="true" toc="include" removeInRFC="false" pn="section-3">
<name slugifiedName="name-the-lost-validation-applica">The LoST-Validation Application Service Tag</name>
<t indent="0" pn="section-3-1">This document adds 'LoST-Validation' to the "S-NAPTR Application
Service Tags" registry created by <xref target="RFC3958" format="default" sectionFormat="of" derivedContent="RFC3958"/>. The 'LoST-Validation' tag serves as a counterpart
to the 'LoST' tag added by <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/>:
the 'LoST' tag identifies servers able to perform the core mapping
function, while 'LoST-Validation' identifies servers designated for the validation function.</t>
<t indent="0" pn="section-3-2">Because some servers might be configured to provide both mapping and
validation functions, a server identified using the 'LoST' service tag
might also perform the validation function (and resolving the two tags
might result in the same URL). Because the two functions might be
separate, clients seeking a LoST server for location validation can
first try a URI-Enabled NAPTR (U-NAPTR) resolution using the
'LoST-Validation' service tag and can fall back to the 'LoST' service tag if this does not resolve to a usable LoST server.</t>
<t indent="0" pn="section-3-3">LoST <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/> specifies that LoST
servers are located by resolving an AUS using U-NAPTR/DDDS (URI-Enabled
NAPTR / Dynamic Delegation Discovery Service) <xref target="RFC4848" format="default" sectionFormat="of" derivedContent="RFC4848"/> and defines the 'LoST' application service tag. In
order to permit separability of the mapping and validation services
performed using LoST, this document defines the 'LoST-Validation'
service tag. This tag also reduces the likelihood that a client needing
location validation might reach servers that are not performing validation (due to
configuration and/or conditions). NAPTR records for LoST servers available for location validation contain the 'LoST-Validation' service tag. An entity needing to perform location validation using LoST performs the discovery procedure as described in <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/>, except that the 'LoST-Validation' service tag is used in preference to the 'LoST' service tag. For both service tags, the HTTP and HTTPS URL schemes are used. In the absence of any NAPTR records containing the 'LoST-Validation' service tag, the 'LoST' service tag is used. Fallback to the 'LoST' service tag may follow if the 'LoST-Validation' service tag fails to result in a usable LoST server. The discovery procedure with the 'LoST-Validation' service tag might result in the same URL as the 'LoST' service tag, or it may result in a different URL. When the URLs are different, they could lead to the same physical servers or different servers.</t>
</section>
<section anchor="back" numbered="true" toc="include" removeInRFC="false" pn="section-4">
<name slugifiedName="name-backwards-compatibility">Backwards Compatibility</name>
<t indent="0" pn="section-4-1">The primary use of LoST in general, and the location validation functionality in particular, is within the emergency services area. Within North America, the NENA i3 <xref target="NENA-i3" format="default" sectionFormat="of" derivedContent="NENA-i3"/> document specifies how protocols including LoST are used. The i3 document is expected to reference the 'LoST-Validation' service tag and specify its use in both server NAPTR DNS records and client resolution of AUS.</t>
<t indent="0" pn="section-4-2">LoST allows a server to refuse to perform location validation and
defines the 'locationValidationUnavailable' warning. LoST also allows a
server to refer to another server rather than answering itself. So, in a
deployment where a LoST tree has separate server clusters for mapping
and for validation, mapping servers receiving a request for validation
could either perform the validation as requested or return the
'locationValidationUnavailable' warning and potentially also include a
<redirect> element to redirect to a validation server. However,
the <redirect> element contains an AUS, so
unless the AUSs for validation and mapping are different (e.g.,
'ecrf.example.org' and 'lvf.example.org'), we still need a different
service tag to allow for flexible deployment choices (i.e., not
requiring a DNS name convention).</t>
<t indent="0" pn="section-4-3">LoST clients performing emergency services operations in North
America are expected to
comply with the NENA i3 specification and hence support the
'LoST-Validation' service tag when defined. A LoST client implemented
prior to the addition of the 'LoST-Validation' tag would use the 'LoST'
tag to resolve an AUS. Such a client might not be performing location
validation, but if it is, the LoST server it contacts may perform the
service. Even in a deployment where mapping and validation are split,
the data is identical; the split is a load and deployment optimization
strategy. Servers designated for mapping might perform validation when
requested (potentially depending on load or other factors). If an older
client attempts validation using a designated mapping server that
refuses the request, the client will retry later, at which point the
server might provide the function (e.g., if its load or other conditions
have changed). Even
in the case of a designated mapping server that refuses to
perform validation at any time, the server could return a redirect with
a different AUS (e.g., "lvf.example.com") that resolves to a designated
validation server. In the worst case, the client will be
unable to reach a server willing to perform validation and will follow
up (e.g., submit a discrepancy report as specified in NENA i3). The
resolution may be to update the client with the 'LoST-Validation'
service tag, update the AUS returned in a redirect and DNS to use a
different DNS host name, or permit the server to perform validation when
not under stress (or a combination). Note that, because LoST does not
require servers to perform validation, the situation described can exist
regardless of the addition of the 'LoST-Validation' service tag. Use of
the tag improves the likelihood that a client is able to validate a
location when needed.</t>
</section>
<section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-5">
<name slugifiedName="name-security-considerations">Security Considerations</name>
<t indent="0" pn="section-5-1">The security considerations described in <xref target="RFC3958" format="default" sectionFormat="of" derivedContent="RFC3958"/>, <xref target="RFC4848" format="default" sectionFormat="of" derivedContent="RFC4848"/>, and <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/> apply here. No additional security
aspects are foreseen by the addition of an extra tag. Separation of
services might be desired, for example, to be able to allocate different levels of resources (such as server capacity, attack mitigation, bandwidth, etc.) to the mapping and validation services, in which case separate tags are needed to allow LoST clients (which may include other LoST servers) to identify the correct server cluster.</t>
<t indent="0" pn="section-5-2"><xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/> descriptively discusses the
use of DNS security <xref target="RFC4033" format="default" sectionFormat="of" derivedContent="RFC4033"/> to
mitigate the risk of DNS-based attacks. Because DNS security has become
more widely deployed since the publication of <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/>, such measures <bcp14>SHOULD</bcp14> be used when
performing NAPTR resolution. Note that, while there are valid reasons
to proceed with a LoST mapping query despite security failures while
initiating or processing an emergency call, these concerns generally do
not apply to a LoST validation query done in advance of an emergency
call.</t>
</section>
<section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn="section-6">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-6-1">IANA has added 'LoST-Validation' to the "S-NAPTR Application Service
Tags" registry created by <xref target="RFC3958" format="default" sectionFormat="of" derivedContent="RFC3958"/>.
This tag serves as a counterpart to the 'LoST' tag added by <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/>.</t>
<t indent="0" pn="section-6-2">(Note that IANA and <xref target="RFC3958" format="default" sectionFormat="of" derivedContent="RFC3958"/> call this registry "S-NAPTR Application Service Tags", while <xref target="RFC5222" format="default" sectionFormat="of" derivedContent="RFC5222"/> calls it "U-NAPTR application service tag".)</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
<name slugifiedName="name-s-naptr-registration">S-NAPTR Registration</name>
<t indent="0" pn="section-6.1-1">This document registers an S-NAPTR application service tag:</t>
<dl spacing="normal" indent="3" newline="false" pn="section-6.1-2">
<dt pn="section-6.1-2.1">Application Service Tag:</dt>
<dd pn="section-6.1-2.2">LoST-Validation</dd>
<dt pn="section-6.1-2.3">Defining Publication:</dt>
<dd pn="section-6.1-2.4">This document</dd>
</dl>
</section>
</section>
</middle>
<back>
<references pn="section-7">
<name slugifiedName="name-references">References</name>
<references pn="section-7.1">
<name slugifiedName="name-normative-references">Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="March"/>
<abstract>
<t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3958" target="https://www.rfc-editor.org/info/rfc3958" quoteTitle="true" derivedAnchor="RFC3958">
<front>
<title>Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)</title>
<author initials="L." surname="Daigle" fullname="L. Daigle">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Newton" fullname="A. Newton">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="January"/>
<abstract>
<t indent="0">This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3958"/>
<seriesInfo name="DOI" value="10.17487/RFC3958"/>
</reference>
<reference anchor="RFC4033" target="https://www.rfc-editor.org/info/rfc4033" quoteTitle="true" derivedAnchor="RFC4033">
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials="R." surname="Arends" fullname="R. Arends">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Austein" fullname="R. Austein">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Larson" fullname="M. Larson">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Massey" fullname="D. Massey">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Rose" fullname="S. Rose">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="March"/>
<abstract>
<t indent="0">The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4033"/>
<seriesInfo name="DOI" value="10.17487/RFC4033"/>
</reference>
<reference anchor="RFC4848" target="https://www.rfc-editor.org/info/rfc4848" quoteTitle="true" derivedAnchor="RFC4848">
<front>
<title>Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)</title>
<author initials="L." surname="Daigle" fullname="L. Daigle">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="April"/>
<abstract>
<t indent="0">The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4848"/>
<seriesInfo name="DOI" value="10.17487/RFC4848"/>
</reference>
<reference anchor="RFC5222" target="https://www.rfc-editor.org/info/rfc5222" quoteTitle="true" derivedAnchor="RFC5222">
<front>
<title>LoST: A Location-to-Service Translation Protocol</title>
<author initials="T." surname="Hardie" fullname="T. Hardie">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Newton" fullname="A. Newton">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="August"/>
<abstract>
<t indent="0">This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5222"/>
<seriesInfo name="DOI" value="10.17487/RFC5222"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references>
<references pn="section-7.2">
<name slugifiedName="name-informative-references">Informative References</name>
<reference anchor="NENA-i3" target="https://www.nena.org/page/i3_Stage3" quoteTitle="true" derivedAnchor="NENA-i3">
<front>
<title>Detailed Functional and Interface Standards for the NENA i3 Solution</title>
<author fullname="" initials="" surname="National Emergency Number Association (NENA) Interconnection and Security Committee, i3 Architecture Working Group"/>
<date year="2016"/>
</front>
</reference>
<reference anchor="RFC5582" target="https://www.rfc-editor.org/info/rfc5582" quoteTitle="true" derivedAnchor="RFC5582">
<front>
<title>Location-to-URL Mapping Architecture and Framework</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="September"/>
<abstract>
<t indent="0">This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5582"/>
<seriesInfo name="DOI" value="10.17487/RFC5582"/>
</reference>
</references>
</references>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.a-1">Many thanks to <contact fullname="Ted Hardie"/>, <contact fullname="Ben Campbell"/>, <contact fullname="Dan Banks"/>, <contact fullname="Pete Resnick"/>, <contact fullname="Shawn Emery"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Benjamin Kaduk"/> for their helpful reviews and suggestions and to <contact fullname="Barry Leiba"/> for shepherding the document.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization showOnFrontPage="true">Core Technology Consulting</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>United States of America</country>
</postal>
<email>rg+ietf@coretechnologyconsulting.com</email>
<uri>http://www.coretechnologyconsulting.com</uri>
</address>
</author>
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization showOnFrontPage="true"/>
<address>
<postal>
<street>470 Conrad Dr.</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>United States of America</country>
</postal>
<phone></phone>
<email>br@brianrosen.net</email>
</address>
</author>
</section>
</back>
</rfc>
|
