idnits 2.17.1 draft-boschi-ipfix-exporting-type-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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 24, 2007) is 6089 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) == Unused Reference: 'I-D.ietf-ipfix-biflow' is defined on line 506, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-25 == Outdated reference: A later version (-11) exists of draft-ietf-psamp-info-06 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group E. Boschi 3 Internet-Draft Hitachi Europe 4 Intended status: Standards Track B. Trammell 5 Expires: February 25, 2008 CERT/NetSA 6 L. Mark 7 T. Zseby 8 Fraunhofer FOKUS 9 August 24, 2007 11 Exporting Type Information for IPFIX Information Elements 12 draft-boschi-ipfix-exporting-type-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on February 25, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document describes an extension to IPFIX to allow the encoding 46 of IPFIX Information Model properties within an IPFIX Message stream, 47 to allow the export of extended type information for enterprise- 48 specific Information Elements. This format is designed to facilitate 49 interoperability and reusability among a wide variety of applications 50 and tools. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Type Information Export . . . . . . . . . . . . . . . . . . . 3 57 3.1. informationElementDataType . . . . . . . . . . . . . . . . 4 58 3.2. informationElementDescription . . . . . . . . . . . . . . 5 59 3.3. informationElementName . . . . . . . . . . . . . . . . . . 5 60 3.4. informationElementRangeBegin . . . . . . . . . . . . . . . 5 61 3.5. informationElementRangeEnd . . . . . . . . . . . . . . . . 6 62 3.6. informationElementSemantics . . . . . . . . . . . . . . . 6 63 3.7. informationElementUnits . . . . . . . . . . . . . . . . . 7 64 3.8. privateEnterpriseNumber . . . . . . . . . . . . . . . . . 8 65 3.9. Information Element Type Options Template . . . . . . . . 8 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . . . . 17 76 1. Introduction 78 The IPFIX protocol specification allows the creation of enterprise- 79 specific Information Elements to easily extend the protocol to meet 80 requirements which aren't covered by the existing Information Model. 81 However, IPFIX Templates provide only the ability to export the size 82 of the fields defined by these Information Elements; there is no 83 mechanism to provide full type information for these Information 84 Elements as is defined for the Information Elements in the IPFIX 85 Information Model. 87 This limits the interoperability of enterprise-specific Information 88 Elements. It is not possible to use analysis tools on IPFIX records 89 containing these partially defined Information Elements that have not 90 been developed with a priori knowledge of their types, since such 91 tools will not be able to decode them; these tools can only treat and 92 store them as opaque octet arrays. However, if richer information is 93 available, additional operations such as efficient storage, display, 94 and limited analysis of records containing enterprise-specific 95 Information Elements become possible, even for Collecting Processes 96 that had not been specifically developed to understand them. 98 This document proposes a mechanism to encode the full set of 99 properties available for the definition of Information Elements 100 within the IPFIX Information Model inline within an IPFIX Message 101 stream using IPFIX Options. This mechanism may be used to fully 102 define type information for Information Elements used within a 103 message stream, without resort to an external reference or reliance 104 on out-of-band configuration. 106 2. Terminology 108 Terms used in this document that are defined in the Terminology 109 section of the IPFIX Protocol [I-D.ietf-ipfix-protocol] document are 110 to be interpreted as defined there. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 3. Type Information Export 118 This section describes the mechanism used to encode Information 119 Element type information within an IPFIX Message stream. This 120 mechanism consists of an Options Template Record used to define 121 Information Element type records, and a set of Information Elements 122 required by these type records. We first specify the necessary 123 Information Elements, followed by the Information Element Type 124 Options Template itself. Note that Information Element type records 125 require one Information Element, informationElementId, that is 126 defined in the PSAMP Information Model [I-D.ietf-psamp-info]. 128 3.1. informationElementDataType 130 Description: A description of the storage type of an IPFIX 131 information element. These correspond to the abstract data types 132 defined in section 3.1 of the IPFIX Information Model 133 [I-D.ietf-ipfix-info]; see that section for more information on 134 the types described below. This field may take the following 135 values: 137 +-------+----------------------+ 138 | Value | Description | 139 +-------+----------------------+ 140 | 0x00 | octetArray | 141 | 0x01 | unsigned8 | 142 | 0x02 | unsigned16 | 143 | 0x03 | unsigned32 | 144 | 0x04 | unsigned64 | 145 | 0x05 | signed8 | 146 | 0x06 | signed16 | 147 | 0x07 | signed32 | 148 | 0x08 | signed64 | 149 | 0x09 | float32 | 150 | 0x0A | float64 | 151 | 0x0B | boolean | 152 | 0x0C | macAddress | 153 | 0x0D | string | 154 | 0x0E | dateTimeSeconds | 155 | 0x0F | dateTimeMilliseconds | 156 | 0x10 | dateTimeMicroseconds | 157 | 0x11 | dateTimeNanoseconds | 158 | 0x12 | ipv4Address | 159 | 0x13 | ipv6Address | 160 +-------+----------------------+ 162 These types are registered in the IANA IPFIX Information Element 163 Data Type subregistry; new types may be added subject to Expert 164 Review [RFC2434]. 166 Abstract Data Type: unsigned8 167 ElementId: TBD1 169 Status: Proposed 171 Reference: Section 3.1 of the IPFIX Information Model 173 3.2. informationElementDescription 175 Description: A string containing a human-readable description of an 176 Information Element. 178 Abstract Data Type: string 180 Data Type Semantics: identifier 182 ElementId: TBD2 184 Status: Proposed 186 3.3. informationElementName 188 Description: A string containing the name of an Information 189 Element. 191 Abstract Data Type: string 193 Data Type Semantics: identifier 195 ElementId: TBD3 197 Status: Proposed 199 3.4. informationElementRangeBegin 201 Description: Contains the inclusive low end of the range of 202 acceptable values for an Information Element. Not valid and 203 SHOULD be ignored by a Collecting Process unless 204 informationElementRangeEnd is also available for the same 205 Information Element. 207 Abstract Data Type: unsigned64 209 Data Type Semantics: quantity 211 ElementId: TBD4 212 Status: Proposed 214 3.5. informationElementRangeEnd 216 Description: Contains the inclusive high end of the range of 217 acceptable values for an Information Element. Not valid and 218 SHOULD be ignored by a Collecting Process unless 219 informationElementRangeBegin is also available for the same 220 Information Element. 222 Abstract Data Type: unsigned64 224 Data Type Semantics: quantity 226 ElementId: TBD5 228 Status: Proposed 230 3.6. informationElementSemantics 232 Description: A description of the semantics of an IPFIX information 233 element. These correspond to the data type semantics defined in 234 section 3.2 of the IPFIX Information Model [I-D.ietf-ipfix-info]; 235 see that section for more information on the types described 236 below. This field may take the following values; the special 237 value 0x00 (none) is used to note that no semantics apply to the 238 field; it cannot be manipulated by a Collecting Process or File 239 Reader that does not understand it a priori. 241 +-------+--------------+ 242 | Value | Description | 243 +-------+--------------+ 244 | 0x00 | none | 245 | 0x01 | quantity | 246 | 0x02 | totalCounter | 247 | 0x03 | deltaCounter | 248 | 0x04 | identifier | 249 | 0x05 | flags | 250 +-------+--------------+ 252 These types are registered in the IANA IPFIX Information Element 253 Semantics subregistry; new types may be added subject to Expert 254 Review [RFC2434]. 256 Abstract Data Type: unsigned8 257 ElementId: TBD6 259 Status: Proposed 261 Reference: Section 3.2 of the IPFIX Information Model 263 3.7. informationElementUnits 265 Description: A description of the units of an IPFIX Information 266 Element. These correspond to the units implicitly defined in the 267 Information Element definitions in section 5 of the IPFIX 268 Information Model [I-D.ietf-ipfix-info]; see that section for more 269 information on the types described below. This field may take the 270 following values; the special value 0x00 (none) is used to note 271 that the field is unitless. 273 +--------+---------------+---------------------------+ 274 | Value | Name | Notes | 275 +--------+---------------+---------------------------+ 276 | 0x0000 | none | | 277 | 0x0001 | bits | | 278 | 0x0002 | octets | | 279 | 0x0003 | packets | | 280 | 0x0004 | flows | | 281 | 0x0005 | seconds | | 282 | 0x0006 | milliseconds | | 283 | 0x0007 | microseconds | | 284 | 0x0008 | nanoseconds | | 285 | 0x0009 | 4-octet words | for IPv4 header length | 286 | 0x000A | messages | for reliability reporting | 287 | 0x000B | hops | for TTL | 288 | 0x000C | entries | for MPLS label stack | 289 +--------+---------------+---------------------------+ 291 These types are registered in the IANA IPFIX Information Element 292 Units subregistry; new types may be added on a First Come First 293 Served [RFC2434] basis. 295 Abstract Data Type: unsigned16 297 ElementId: TBD7 299 Status: Proposed 301 Reference: Section 5 of the IPFIX Information Model 303 3.8. privateEnterpriseNumber 305 Description: A private enterprise number used to scope an 306 informationElementID, as would appear in an IPFIX Template Record. 307 This element can be used to scope properties to a specific 308 Information Element. If the Enterprise ID bit of the 309 corresponding Information Element is cleared (has the value 0), 310 this IE should be set to 0. The presence of a non-zero value in 311 this IE implies that the Enterprise ID bit of the corresponding 312 Information Element is set (has the value 1). 314 Abstract Data Type: unsigned32 316 Data Type Semantics: identifier 318 ElementId: TBD8 320 Status: Proposed 322 Reference: Section 3.4.1 of the IPFIX Protocol draft 324 3.9. Information Element Type Options Template 326 The Information Element Type Options Template attaches type 327 information to Information Elements used within Template Records, as 328 scoped to an Observation Domain within a Transport Session. This 329 provides a mechanism for representing an IPFIX Information Model 330 inline within an IPFIX Message stream. Data Records described by 331 this template are referred to as Information Element type records. 333 In deployments in which interoperability across vendor 334 implementations of IPFIX is important, an Exporting Process exporting 335 data using Templates containing enterprise-specific Information 336 Elements SHOULD export an Information Element type record for each 337 enterprise-specific Information Element it exports. Collecting 338 Processes MAY use these type records to improve handling of unknown 339 enterprise-specific Information Elements. Exporting Processes using 340 enterprise-specific Information Elements to implement proprietary 341 features MAY omit type records for those Information Elements. 343 Information Element type records MUST be handled by Collecting 344 Processes as scoped to the Transport Session in which they are sent; 345 this facility is not intended to provide a method for the permanent 346 definition of Information Elements. 348 Similarly, for security reasons, type information for a given 349 Information Element MUST NOT be re-defined by Information Element 350 type records. Once an Information Element type record has been 351 exported for a given Information Element within a given Transport 352 Session, all subsequent type records for that Information Element 353 MUST be identical. If conflicting semantic or type information is 354 received in multiple semantics records by a Collecting Process, the 355 Collecting Process MUST reset the Transport Session. 357 The template SHOULD contain the following Information Elements as 358 defined in the PSAMP Information Model [I-D.ietf-psamp-info] and in 359 this document, above: 361 +-------------------------------+-----------------------------------+ 362 | IE | Description | 363 +-------------------------------+-----------------------------------+ 364 | informationElementID | The Information Element | 365 | | identifier of the Information | 366 | | Element within the specified | 367 | | Template this record describes. | 368 | | This Information Element MUST be | 369 | | defined as a Scope Field. See | 370 | | the PSAMP Information Model | 371 | | [I-D.ietf-psamp-info] for a | 372 | | definition of this field. | 373 | privateEnterpriseNumber | The Private Enterprise number of | 374 | | the Information Element within | 375 | | the specified Template this | 376 | | record describes. This | 377 | | Information Element MUST be | 378 | | defined as a Scope Field. | 379 | informationElementDataType | The storage type of the specified | 380 | | Information Element. | 381 | informationElementSemantics | The semantic type of the | 382 | | specified Information Element. | 383 | informationElementUnits | The units of the specified | 384 | | Information Element. This | 385 | | element MAY be omitted if the | 386 | | Information Element is a unitless | 387 | | quantity, or a not a quantity or | 388 | | counter. | 389 | informationElementRangeBegin | The low end of the range of | 390 | | acceptable values for the | 391 | | specified Information Element. | 392 | | This element MAY be omitted if | 393 | | the Information Element's | 394 | | acceptable range is defined by | 395 | | its data type. | 396 | informationElementRangeEnd | The high end of the range of | 397 | | acceptable values for the | 398 | | specified Information Element. | 399 | | This element MAY be omitted if | 400 | | the Information Element's | 401 | | acceptable range is defined by | 402 | | its data type. | 403 | informationElementName | The name of the specified | 404 | | Information Element. | 405 | informationElementDescription | A human readable description of | 406 | | the specified Information | 407 | | Element. This element MAY be | 408 | | omitted in the interest of export | 409 | | efficiency. | 410 +-------------------------------+-----------------------------------+ 412 4. Security Considerations 414 The same security considerations as for the IPFIX Protocol 415 [I-D.ietf-ipfix-protocol] apply. 417 5. IANA Considerations 419 This document specifies the creation of several new IPFIX Information 420 Elements in the IPFIX Information Element registry located at 421 http://www.iana.org/assignments/ipfix, as defined in section 3 above. 422 IANA has assigned the following Information Element numbers for their 423 respective Information Elements as specified below: 425 o Information Element Number TBD1 for the informationElementDataType 426 Information Element 428 o Information Element Number TBD2 for the 429 informationElementDescription Information Element 431 o Information Element Number TBD3 for the informationElementName 432 Information Element 434 o Information Element Number TBD4 for the 435 informationElementRangeBegin Information Element 437 o Information Element Number TBD5 for the informationElementRangeEnd 438 Information Element 440 o Information Element Number TBD6 for the 441 informationElementSemantics Information Element 443 o Information Element Number TBD7 for the informationElementUnits 444 Information Element 446 o Information Element Number TBD8 for the privateEnterpriseNumber 447 Information Element 449 o [NOTE for IANA: The text TBD1, TBD2, TBD3, TBD4, TBD5, TBD6, TBD7, 450 and TBD8 should be replaced with the respective assigned 451 Information Element numbers where they appear in this document.] 453 IANA has created an Information Element Data Type subregistry for the 454 values defined for the informationElementSemantics Information 455 Element. Entries may be added to this subregistry subject to Expert 456 Review [RFC2434]. 458 [NOTE for IANA: Please create a new Information Element Data Type 459 subregistry as specified in the paragraph above, with initial values 460 taken from section 3.1 of this document.] 462 IANA has created an Information Element Semantics subregistry for the 463 values defined for the informationElementSemantics Information 464 Element. Entries may be added to this subregistry subject to Expert 465 Review [RFC2434]. 467 [NOTE for IANA: Please create a new Information Element Semantics 468 subregistry as specified in the paragraph above, with initial values 469 taken from section 3.6 of this document.] 471 IANA has created an Information Element Units subregistry for the 472 values defined for the informationElementUnits Information Element. 473 Entries may be added to this subregistry on a First Come First Served 474 [RFC2434] basis. 476 [NOTE for IANA: Please create a new Information Element Units 477 subregistry as specified in the paragraph above, with initial values 478 taken from section 3.7 of this document.] 480 6. Acknowledgements 482 Thanks to Paul Aitken for the detailed technical review, and to David 483 Moore for first raising this issue to the IPFIX mailing list. 485 7. References 486 7.1. Normative References 488 [I-D.ietf-ipfix-protocol] 489 Claise, B., "Specification of the IPFIX Protocol for the 490 Exchange of IP Traffic Flow Information", 491 draft-ietf-ipfix-protocol-25 (work in progress), 492 August 2007. 494 [I-D.ietf-ipfix-info] 495 Quittek, J., "Information Model for IP Flow Information 496 Export", draft-ietf-ipfix-info-15 (work in progress), 497 February 2007. 499 [I-D.ietf-psamp-info] 500 Dietz, T., "Information Model for Packet Sampling 501 Exports", draft-ietf-psamp-info-06 (work in progress), 502 June 2007. 504 7.2. Informative References 506 [I-D.ietf-ipfix-biflow] 507 Trammell, B. and E. Boschi, "Bidirectional Flow Export 508 using IPFIX", draft-ietf-ipfix-biflow-05 (work in 509 progress), June 2007. 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 515 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 516 October 1998. 518 Appendix A. Examples 520 The following example illustrates how the type information extension 521 mechanism defined in this document may be used to describe the 522 semantics of enterprise-specific Information Elements. The 523 Information Elements used in this example are as follows: 525 o initialTCPFlags, CERT (PEN 6871) private IE 14, 1 octet, the TCP 526 flags on the first TCP packet in the flow. 528 o unionTCPFlags, CERT (PEN 6871) private IE 15, 1 octet, the union 529 of the TCP flags on all packets after the first TCP packet in the 530 flow. 532 An Exporting Process exporting flows containing these Information 533 Elements might use a Template like the following: 535 1 2 3 536 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Set ID = 2 | Length = 52 | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Template ID = 256 | Field Count = 9 | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |0| flowStartSeconds 150 | Field Length = 4 | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 |0| sourceIPv4Address 8 | Field Length = 4 | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 |0| destinationIPv4Address 12 | Field Length = 4 | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 |0| sourceTransportPort 7 | Field Length = 2 | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |0| destinationTransportPort 11 | Field Length = 2 | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 |0| octetTotalCount 85 | Field Length = 4 | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |1| (initialTCPFlags) 14 | Field Length = 1 | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | PEN 6871 | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 |1| (unionTCPFlags) 15 | Field Length = 1 | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | PEN 6871 | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |0| protocolIdentifier 4 | Field Length = 1 | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Figure 1: Template with Enterprise-Specific IEs 567 However, a Collecting Process receiving Data Sets described by this 568 Template can only treat the enterprise-specific Information Elements 569 as opaque octets; specifically, there is no hint to the collector 570 that they contain flag information. To use the type information 571 extension mechanism to address this problem, the Exporting Process 572 would first export the Information Element Type Options Template 573 described in section 3.9 above: 575 1 2 3 576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Set ID = 3 | Length = 26 | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Template ID = 257 | Field Count = 4 | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Scope Field Count = 2 |0| priv.EnterpriseNumber TBD8 | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Field Length = 4 |0| informationElementId 303 | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Field Length = 2 |0| inf.El.DataType TBD1 | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Field Length = 1 |0| inf.El.Semantics TBD6 | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Field Length = 1 |0| inf.El.Name TBD3 | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Field Length = 65536 | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 2: Example Information Element Type Options Template 597 Then, the Exporting Process would then export two records described 598 by the Example Information Element Type Options Template to describe 599 the enterprise-specific Information Elements: 601 1 2 3 602 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Set ID = 257 | Length = 50 | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | PEN 6871 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | IE 14 |0x01 unsigned8 |0x05 flags | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | 15 length | | 611 +-+-+-+-+-+-+-+-+ | 612 | "initialTCPFlags" | 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | PEN 6871 | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | IE 15 |0x01 unsigned8 |0x05 flags | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | 13 length | | 620 +-+-+-+-+-+-+-+-+ "unionTCPFlags" | 621 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Figure 3: Type Information Extension Example 627 Authors' Addresses 629 Elisa Boschi 630 Hitachi Europe SAS 631 Immeuble Le Theleme 632 1503 Route des Dolines 633 06560 Valbonne 634 France 636 Phone: +33 4 89874100 637 Email: elisa.boschi@hitachi-eu.com 638 Brian H. Trammell 639 CERT Network Situational Awareness 640 Software Engineering Institute 641 4500 Fifth Avenue 642 Pittsburgh, Pennsylvania 15213 643 United States 645 Phone: +1 412 268 9748 646 Email: bht@cert.org 648 Lutz Mark 649 Fraunhofer Institute for Open Communication Systems 650 Kaiserin-Augusta-Allee 31 651 10589 Berlin 652 Germany 654 Phone: +49 30 3463 7306 655 Email: lutz.mark@fokus.fraunhofer.de 657 Tanja Zseby 658 Fraunhofer Institute for Open Communication Systems 659 Kaiserin-Augusta-Allee 31 660 10589 Berlin 661 Germany 663 Phone: +49 30 3463 7153 664 Email: tanja.zseby@fokus.fraunhofer.de 666 Full Copyright Statement 668 Copyright (C) The IETF Trust (2007). 670 This document is subject to the rights, licenses and restrictions 671 contained in BCP 78, and except as set forth therein, the authors 672 retain all their rights. 674 This document and the information contained herein are provided on an 675 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 676 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 677 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 678 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 679 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 680 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 682 Intellectual Property 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use of 696 such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at 704 ietf-ipr@ietf.org. 706 Acknowledgment 708 Funding for the RFC Editor function is provided by the IETF 709 Administrative Support Activity (IASA).