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
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Internet Research Task Force (IRTF) S. Symington
Request for Comments: 6258 The MITRE Corporation
Category: Experimental May 2011
ISSN: 2070-1721
<span class="h1">Delay-Tolerant Networking Metadata Extension Block</span>
Abstract
This document defines an extension block that may be used with the
Delay-Tolerant Networking (DTN) Bundle Protocol. This Metadata
Extension Block is designed to carry additional information that DTN
nodes can use to make processing decisions regarding bundles, such as
deciding whether to store a bundle or determining to which nodes to
forward a bundle. The metadata that is carried in a metadata block
must be formatted according to the metadata type that is identified
in the block's metadata type field. One specific metadata type, for
carrying URIs as metadata, is defined in this document. Other
metadata types may be defined in separate documents. This document
is a product of the Delay Tolerant Networking Research Group and has
been reviewed by that group. No objections to its publication as an
RFC were raised.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Research Task
Force (IRTF). The IRTF publishes the results of Internet-related
research and development activities. These results might not be
suitable for deployment. This RFC represents the consensus of the
Delay-Tolerant Networking Research Group of the Internet Research
Task Force (IRTF). Documents approved for publication by the IRSG
are not a candidate for any level of Internet Standard; see <a href="./rfc5741#section-2">Section 2
of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6258">http://www.rfc-editor.org/info/rfc6258</a>.
<span class="grey">Symington Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6258">RFC 6258</a> DTN Metadata Extension Block May 2011</span>
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Requirements Language ......................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Metadata Block Format ...........................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Metadata Block Processing .......................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Bundle Transmission ........................................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Bundle Forwarding ..........................................<a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. Bundle Reception ...........................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Predefined Metadata Types .......................................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. URI Metadata Type ..........................................<a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Private Metadata Types .....................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. IANA Considerations .............................................<a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. Metadata Type Codes ........................................<a href="#page-8">8</a>
<a href="#section-6.2">6.2</a>. Block Type Code for the Metadata Block .....................<a href="#page-9">9</a>
<a href="#section-7">7</a>. References ......................................................<a href="#page-9">9</a>
<a href="#section-7.1">7.1</a>. Normative References .......................................<a href="#page-9">9</a>
<a href="#section-7.2">7.2</a>. Informative References .....................................<a href="#page-9">9</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document defines an extension block that may be used with the
Bundle Protocol [<a href="./rfc5050" title=""Bundle Protocol Specification"">RFC5050</a>] within the context of a Delay-Tolerant
Networking architecture [<a href="./rfc4838" title=""Delay-Tolerant Networking Architecture"">RFC4838</a>]. The DTN Bundle Protocol [<a href="./rfc5050" title=""Bundle Protocol Specification"">RFC5050</a>]
defines the bundle as its protocol data unit. This document defines
a bundle block called a "metadata block". This block is designed to
carry additional information that DTN nodes can use to make
processing decisions regarding bundles.
The metadata block has been deliberately defined to be flexible
enough that it would be capable of supporting a variety of metadata
types and formats. Indeed, the only restriction imposed on the
metadata to be used is that its type and format be predefined and
registered (if public) so that it can be parsed and processed by DTN
nodes that support metadata of that type. <a href="#section-4">Section 4</a> defines a
<span class="grey">Symington Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6258">RFC 6258</a> DTN Metadata Extension Block May 2011</span>
specific metadata type and discusses the use of other metadata types
that may be defined elsewhere. As mentioned, it is the intention
that the metadata that is carried in this block be application-
related information. For example, the metadata might be information
that is associated with the payload of a bundle. Additional
extension blocks could be (and have been) defined for carrying
additional network-related information.
While the bundle payload may be processed opaquely by DTN nodes,
metadata is intended to serve as a mechanism for providing DTN nodes
with access to additional information that they can use to process
the bundle. Examples of such additional information include keywords
found in the payload; payload provenance information; GPS coordinates
(if the payload is a map, for instance); message IDs; and artist,
album, and track name (if the payload is a song). Even though the
metadata is additional information related to the application, its
purpose is to be used by DTN nodes to make decisions regarding how to
process bundles within the network, such as whether or not a bundle
should be stored or to which nodes a bundle should be forwarded.
Metadata that is about bundle payload, for example, might serve as a
content-based index of bundles that are stored in a DTN cache. So,
in response to a request for bundles related to a certain subject or
related to specific GPS coordinates, for example, the metadata of
stored bundles could be searched, and all bundles with metadata
matching the search criteria could be retrieved and returned to the
requestor.
This document defines the general format of and the processing
required to support the metadata block. The actual metadata to be
inserted into a metadata block MUST be formatted according to the
metadata type that is identified in the block's metadata type field.
One specific metadata type, for carrying Uniform Resource Identifiers
(URIs) [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] as metadata, is defined in this document. Other
metadata types may be defined in separate documents, along with the
steps required to process records of that type, if necessary. If
such other metadata types are defined, they should be registered to
ensure global uniqueness (see the IANA Considerations section).
The capabilities described in this document are OPTIONAL for
deployment with the Bundle Protocol. As defined in this document,
Bundle Protocol implementations claiming to support the metadata
block MUST be capable of:
- generating a metadata block and inserting it into a bundle,
<span class="grey">Symington Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6258">RFC 6258</a> DTN Metadata Extension Block May 2011</span>
- receiving bundles containing a metadata block and making the
information contained in this metadata block's metadata field
available for use, e.g., in bundle storage or forwarding
decisions, and
- deleting a metadata block from a received bundle before
forwarding the bundle.
Bundle Protocol implementations claiming to support a specific
metadata type must both support the metadata block as defined above
and be capable of parsing and processing the metadata itself
according to the definition of the metadata type in which the
metadata is expressed. This metadata type may be the URI metadata
type (see the URI metadata type section), or it may be another
metadata type defined in a separate document.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Metadata Block Format</span>
The metadata block uses the Canonical Bundle Block Format as defined
in the Bundle Protocol [<a href="./rfc5050" title=""Bundle Protocol Specification"">RFC5050</a>]. That is, it is comprised of the
following elements, which are defined as in all bundle protocol
blocks except the primary bundle block. (Note that Self-Delimiting
Numeric Value (SDNV) encoding is described in the Bundle Protocol.):
- Block-type code (1 byte) - defined as in all bundle protocol
blocks except the primary bundle block (as described in the Bundle
Protocol). The block-type code for the metadata block is 0x08.
- Block processing control flags (SDNV) - defined as in all bundle
protocol blocks except the primary bundle block. SDNV encoding is
described in the Bundle Protocol. There are no constraints on the
use of the block processing control flags. If a bundle node
receives a bundle with a metadata block and it is capable of
supporting the metadata block but it is not able to parse and
process the metadata itself, either because it does not support
the metadata type being used or because the metadata is not well-
formed according to the metadata type definition, the bundle node
must process the bundle as if it cannot process the metadata
block. That is, it must operate according to the settings of the
block processing control flags, including the "Delete bundle if
block can't be processed" flag and the "Discard block if it can't
be processed" flag.
<span class="grey">Symington Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6258">RFC 6258</a> DTN Metadata Extension Block May 2011</span>
- Block EID-reference count and EID-references (optional) -
composite field defined in the Bundle Protocol that is present if
and only if the metadata block references EID elements in the
primary block's dictionary. Presence of this field is indicated
by the setting of the "Block contains an EID-reference field" bit
of the block processing control flags. If EIDs are referenced in
the metadata block, then their interpretation is defined by the
particular metadata type that is being used in this metadata
block, as indicated in the metadata type field.
- Block data length (SDNV) - defined as in all bundle protocol
blocks except the primary bundle block. SDNV encoding is
described in the Bundle Protocol.
- Block-type-specific data fields as follows:
- Metadata Type field (SDNV) - indicates which metadata type is
to be used to interpret both the metadata in the metadata field
and the EID-references in the optional Block EID-reference
count and EID-references field (if present). One metadata type
is defined in this document. Other metadata types may be
defined in separate documents.
- Metadata field - contains the metadata itself, formatted
according to the metadata type that has been specified for this
block. One metadata type is defined in <a href="#section-4.1">Section 4.1</a>. Other
metadata types may be defined elsewhere, as discussed in
<a href="#section-4">Section 4</a>.
The structure of a metadata block is as follows:
Metadata Block Format:
+-----+------+--------------------+------+----------+----------|
|Type |Flags |EID-Reference count |Len | Metadata | Metadata |
| |(SDNV)| and list (opt) |(SDNV)| Type | |
+-----+------+--------------------+------+----------+----------+
Figure 1
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Metadata Block Processing</span>
The following are the processing steps that a bundle node may take
relative to generation, reception, and processing of metadata blocks.
<span class="grey">Symington Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6258">RFC 6258</a> DTN Metadata Extension Block May 2011</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Bundle Transmission</span>
When an outbound bundle is created per the parameters of the bundle
transmission request, this bundle MAY (as influenced by local policy
and the metadata type being used) include one or more metadata blocks
(as defined in this specification).
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Bundle Forwarding</span>
A node MAY insert one or more metadata blocks into a bundle before
forwarding it; and a node MAY delete one or more metadata blocks from
a bundle before forwarding it, as dictated by local policy and the
metadata type being used.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Bundle Reception</span>
If the bundle includes one or more metadata blocks, the metadata
information records in these blocks SHALL be made available for use
at this node (e.g., in bundle storage or forwarding decisions, or, if
the receiving node is the bundle-destination, the metadata
information records may be provided to the receiving application).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Predefined Metadata Types</span>
As mentioned in the previous section, any number of different
metadata types may be defined to indicate the format of both the
metadata field and the EID-references in the optional Block EID-
reference count and EID-references field (if present) and, if
necessary, how metadata of this type should be processed. One
metadata type is defined in this document, URI metadata type (0x01).
In addition, a range of metadata type values is reserved for private
use.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. URI Metadata Type</span>
It is believed that use of URIs will, in many cases, be adequate for
encoding metadata, although it is recognized that use of URIs may not
be the most efficient method for such encoding. Because of the
expected utility of using URI encoding for metadata, the metadata
type value of 0x01 is defined to indicate a metadata type of URI.
Metadata type values other than 0x01 will be used to indicate
alternative metadata types.
The Metadata field for metadata of metadata type URI (0x01) consists
of an array of bytes formed by concatenating one or more null-
terminated URIs. Unless determined by local policy, the specific
processing steps that must be performed on bundles with metadata
blocks containing metadata of type URI are expected to be indicated
<span class="grey">Symington Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6258">RFC 6258</a> DTN Metadata Extension Block May 2011</span>
as part of the URI encoding of the metadata. It is envisioned that
users might define URI schemes for this purpose. Metadata blocks
containing metadata of type URI MUST NOT include a Block EID-
reference count and EID-references field. The absence of this field
MUST be indicated by a value of 0 for the "Block contains an EID-
reference field" flag in the block processing control flags. Support
for the URI metadata type is OPTIONAL.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Private Metadata Types</span>
Metadata type values 192 through 255 are not defined in this
specification and are available for private and/or experimental use.
Such private metadata types are not required to be registered. All
other values of the metadata type are reserved for future use and,
when defined, should be registered to ensure global uniqueness (see
the IANA Considerations section). Local policy will define how
private metadata types are handled.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The DTN Bundle Security Protocol [<a href="./rfc6257" title=""Bundle Security Protocol Specification"">RFC6257</a>] defines security-related
blocks to provide hop-by-hop authentication, end-to-end
authentication, end-to-end confidentiality of bundles or parts of
bundles, and an extension security block to provide confidentiality
and integrity for extension blocks, as well as a set of standard
ciphersuites that may be used to calculate security-results carried
in these security blocks. All ciphersuites that use the strict
canonicalization algorithm [<a href="./rfc6257" title=""Bundle Security Protocol Specification"">RFC6257</a>] to calculate and verify
security-results (e.g., many hop-by-hop authentication ciphersuites)
apply to all blocks in the bundle and so would apply to bundles that
include an optional metadata block and would include that block in
the calculation of their security-result. In particular, bundles
including the optional metadata block would be protected in their
entirety for the duration of a single hop, from a forwarding node to
an adjacent receiving node (but not from source to destination over
multiple hops), using the standard BAB-HMAC (Bundle Authentication
Block - Hashed Message Authentication Code) ciphersuite defined in
the Bundle Security Protocol.
Ciphersuites that use the mutable canonicalization algorithm to
calculate and verify security-results (e.g., the mandatory PSH-RSA-
SHA256 ciphersuite and most end-to-end authentication ciphersuites)
will omit the metadata block from their calculation. Therefore, the
fact that metadata in the metadata block may be modified or that
metadata blocks themselves may be added to or deleted from a bundle
as it transits the network will not interfere with end-to-end
security protection when using ciphersuites that use mutable
canonicalization.
<span class="grey">Symington Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6258">RFC 6258</a> DTN Metadata Extension Block May 2011</span>
The metadata block will not be encrypted by the mandatory CH-RSA-AES-
PAYLOAD-PSH end-to-end confidentiality ciphersuite, which only allows
for payload and PSH encryption.
In order to provide the metadata block with end-to-end
confidentiality and authentication independent of any confidentiality
or authentication that is provided for the payload or other parts of
the bundle, the extension security block may be used to encrypt and
authenticate the metadata block. A bundle may contain multiple
metadata extension blocks. In some cases, multiple metadata blocks
may be carried in the bundle, possibly with each being encrypted
separately from each other and from the payload. Such separate
encryption of metadata from payload would enable bundle nodes to
perform content-based searching and routing on bundle metadata that
they are able to decrypt, even if they are not able to decrypt the
bundle payload.
Given that metadata can be modified by forwarding nodes, it may be
desirable to eventually support the ability to audit changes to the
metadata at the individual record level. No such capability has been
provided in this specification as currently written.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Metadata Type Codes</span>
The metadata block carried in the Metadata Extension Block has a
Metadata Type Code field (see Sections <a href="#section-2">2</a> and <a href="#section-3">3</a>). An IANA registry
has been set up as follows.
Metadata Type Codes Registry
The registration policy for this registry is:
0-191: Specification Required
192-255: Private and/or Experimental Use. No assignment by IANA.
The Value range is unsigned 8-bit integer.
+---------+---------------------------------+---------------+
| Value | Description | Reference |
+---------+---------------------------------+---------------+
| 0 | Reserved | This document |
| 1 | URI | This document |
| 2-191 | Unassigned | |
| 192-255 | Private and/or experimental use | This document |
+---------+---------------------------------+---------------+
<span class="grey">Symington Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6258">RFC 6258</a> DTN Metadata Extension Block May 2011</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Block Type Code for the Metadata Block</span>
This specification allocates a codepoint from the Bundle Block Type
Codes registry defined in [<a href="./rfc6255" title=""Delay-Tolerant Networking (DTN) Bundle Protocol IANA Registries"">RFC6255</a>] (see <a href="#section-2">Section 2</a> of this document):
Additional Entry for the Bundle Block Type Codes Registry:
+-------+----------------------------------------+----------------+
| Value | Description + Reference |
+-------+----------------------------------------+----------------+
| 8 | Metadata Extension Block + This document |
+-------+----------------------------------------+----------------+
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
<a href="./rfc3986">RFC 3986</a>, January 2005.
[<a id="ref-RFC5050">RFC5050</a>] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", <a href="./rfc5050">RFC 5050</a>, November 2007.
[<a id="ref-RFC6255">RFC6255</a>] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle
Protocol IANA Registries", <a href="./rfc6255">RFC 6255</a>, May 2010.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC4838">RFC4838</a>] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", <a href="./rfc4838">RFC 4838</a>, April 2007.
[<a id="ref-RFC6257">RFC6257</a>] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", <a href="./rfc6257">RFC 6257</a>,
May 2011.
<span class="grey">Symington Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6258">RFC 6258</a> DTN Metadata Extension Block May 2011</span>
Author's Address
Susan Flynn Symington
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-7209
EMail: susan@mitre.org
URI: <a href="http://mitre.org/">http://mitre.org/</a>
Symington Experimental [Page 10]
</pre>
|
