idnits 2.17.1 draft-trammell-ipfix-ie-doctors-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 28, 2011) is 4564 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 1101 == Unused Reference: 'RFC3917' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 1212, but no explicit reference was found in the text == Unused Reference: 'RFC5153' is defined on line 1215, but no explicit reference was found in the text == Unused Reference: 'RFC5470' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'RFC5471' is defined on line 1223, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3954 ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: BCP B. Claise 5 Expires: April 30, 2012 Cisco Systems, Inc. 6 October 28, 2011 8 Guidelines for Authors and Reviewers of IPFIX Information Elements 9 draft-trammell-ipfix-ie-doctors-03.txt 11 Abstract 13 This document provides guidelines for the definition of IPFIX 14 Information Elements for addition to the IANA IPFIX Information 15 Element registry, in order to extend the applicability of the IPFIX 16 protocol to new operations and management areas. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 30, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Intended Audience and Usage . . . . . . . . . . . . . . . 3 54 1.2. Overview of relevant IPFIX documents . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. How to apply IPFIX . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Defining new Information Elements . . . . . . . . . . . . . . 6 58 4.1. Information Element naming . . . . . . . . . . . . . . . . 6 59 4.2. Information Element data types . . . . . . . . . . . . . . 7 60 4.3. Information Element numbering . . . . . . . . . . . . . . 8 61 4.4. Ancillary Information Element properties . . . . . . . . . 8 62 4.5. Internal structure in Information Elements . . . . . . . . 9 63 4.6. Information Element multiplicity . . . . . . . . . . . . . 10 64 4.7. Enumerated Values and Subregistries . . . . . . . . . . . 10 65 4.8. Reversibility as per RFC 5103 . . . . . . . . . . . . . . 11 66 4.9. Promotion of Enterprise-Specific Information Elements . . 11 67 4.10. Avoiding Bad Ideas in Information Element Design . . . . . 11 68 5. The Information Element Lifecycle . . . . . . . . . . . . . . 12 69 5.1. The IE-DOCTORS process . . . . . . . . . . . . . . . . . . 13 70 5.2. Revising Information Elements . . . . . . . . . . . . . . 13 71 5.3. Deprecating Information Elements . . . . . . . . . . . . . 14 72 5.4. Versioning the entire IANA Registry . . . . . . . . . . . 15 73 6. When not to define new Information Elements . . . . . . . . . 16 74 6.1. Maximizing reuse of existing Information Elements . . . . 16 75 6.2. Applying enterprise-specific Information Elements . . . . 17 76 7. Applying IPFIX to non-Flow Applications . . . . . . . . . . . 18 77 8. Writing Internet-Drafts for IPFIX Applications . . . . . . . . 18 78 8.1. Example Information Element Definition . . . . . . . . . . 19 79 8.2. Defining Recommended Templates . . . . . . . . . . . . . . 19 80 9. A Textual Format for Specifying Information Elements and 81 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 9.1. Information Element Specifiers . . . . . . . . . . . . . . 21 83 9.2. Specifying Templates . . . . . . . . . . . . . . . . . . . 23 84 9.3. Specifying IPFIX Structured Data . . . . . . . . . . . . . 23 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 87 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 This document provides guidelines for the extension of the 96 applicability of the IP Flow Information Export (IPFIX) protocol to 97 network operations and management purposes outside the initial scope 98 defined in "IPFIX Applicability Statement" [RFC5472]. These new 99 applications are largely defined by creating new Information Elements 100 beyond those in the IANA IPFIX Information Element Registry 101 [iana-ipfix-assignments]. New applications may be further specified 102 through additional RFCs defining and describing their usage. 104 We intend this document to enable the expansion of the applicability 105 of IPFIX to new areas by experts in the working group or area 106 directorate concerned with the technical details of the protocol or 107 application to be measured or managed using IPFIX. This expansion 108 would occur with the consultation of IPFIX experts informally called 109 'IE-Doctors'. It provides guidelines both for those defining new 110 Information Elements as well as the IE-Doctors reviewing them. 112 1.1. Intended Audience and Usage 114 This document is meant for two separate audiences. For IETF 115 contributors extending the applicability of IPFIX, it provides a set 116 of guidelines and best practices to be used in deciding which 117 Information Elements are necessary for a given existing or new 118 application, defining these Information Elements, and deciding 119 whether an RFC should be published to further describe the 120 application. For the IPFIX experts appointed as IE-Doctors, and for 121 IANA personnel changing the Information Element registry, it defines 122 a set of acceptance criteria against which these proposed Information 123 Elements should be evaluated. 125 This document is not intended to guide the extension of the IPFIX 126 protocol itself, e.g. through new export mechanisms, data types, or 127 the like; these activities should be pursued through the publication 128 of standards-track RFCs by the IPFIX Working Group. 130 This document specifies additional practices beyond those appearing 131 in the IANA Considerations sections of existing IPFIX documents, 132 especially the Information Model [RFC5102]. The practices outlined 133 in this document are intended to guide experts when making changes to 134 the IANA registry under Expert Review as defined in [RFC5226]. 136 1.2. Overview of relevant IPFIX documents 138 [RFC5101] defines the IPFIX Protocol, the IPFIX-specific terminology 139 used by this document, and the data type encodings for each of the 140 data types supported by IPFIX. 142 [RFC5102] defines the initial IPFIX Information Model, as well as 143 procedures for extending the Information Model. It states that new 144 Information Elements may be added to the Information Model on Expert 145 Review basis, and delegates the appointment of experts to an IESG 146 Area Director. This document is intended to further codify the best 147 practices to be followed by these experts, in order to improve the 148 efficiency of this process. 150 [RFC5103] defines a method for exporting bidirectional flow 151 information using IPFIX; this document should be followed when 152 extending IPFIX to represent information about bidirectional network 153 interactions in general. Additionally, new Information Elements 154 should be annotated for their reversibility or lack thereof as per 155 this document. 157 [RFC5610] defines a method for exporting information about 158 Information Elements inline within IPFIX. In doing so, it explicitly 159 defines a set of restrictions on the use of data types and semantics 160 which are implied in [RFC5101] and [RFC5102]; these restrictions MUST 161 be observed in the definition of new Information Elements, as in 162 Section 4.4. 164 2. Terminology 166 Capitalized terms used in this document that are defined in the 167 Terminology section of [RFC5101] are to be interpreted as defined 168 there. 170 An "application", as used in this document, refers to a candidate 171 protocol, task, or domain to which IPFIX export, collection, and/or 172 storage is applied, beyond those within the IPFIX Applicability 173 statement [RFC5472]. By this definition, PSAMP [RFC5476] was the 174 first new IPFIX application after the publication of the IPFIX 175 protocol [RFC5101]. 177 "IANA registry", as used in this document, unless otherwise noted, 178 refers to the IANA IPFIX Information Element Registry 179 [iana-ipfix-assignments]. 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 3. How to apply IPFIX 187 Though originally specified for the export of IP flow information, 188 the message format, template mechanism, and data model specified by 189 IPFIX lead to it being applicable to a wide variety of network 190 management situations. In addition to flow information export, for 191 which it was designed, and packet information export as specified by 192 PSAMP [RFC5476], any application with the following characteristics 193 is a good candidate for an IPFIX application: 195 o The application's data flow is fundamentally unidirectional. 196 IPFIX is a "push" protocol, supporting only the export of 197 information from a sender (an Exporting Process) to a receiver (a 198 Collecting Process). Request-response interactions are not 199 supported by IPFIX. 201 o The application handles discrete event information, or information 202 to be periodically reported. IPFIX is particularly well suited to 203 representing events, which can be scoped in time. 205 o The application handles information about network entities. 206 IPFIX's information model is network-oriented, so network 207 management applications have many opportunities for information 208 model reuse. 210 o The application requires a small number of arrangements of data 211 structures relative to the number of records it handles. The 212 template-driven self-description mechanism used by IPFIX excels at 213 handling large volumes of identically structured data, compared to 214 representations which define structure inline with data (such as 215 XML). 217 Most applications meeting these criteria can be supported over IPFIX. 218 Once it's been determined that IPFIX is a good fit, the next step is 219 determining which Information Elements are necessary to represent the 220 information required by the application. Especially for network- 221 centric applications, the IPFIX Information Element registry may 222 already contain all the necessary Information Elements (see 223 Section 6.1 for guidelines on maximizing Information Element reuse). 224 In this case, no additional work within the IETF is necessary: simply 225 define Templates and start exporting. 227 It is expected, however, that most applications will be able to reuse 228 some existing Information Elements, but must define some additional 229 Information Elements to support all their requirements; in this case, 230 see Section 4 for best practices to be followed in defining 231 Information Elements. 233 Optionally, a Working Group or individual contributor may choose to 234 publish an RFC detailing the new IPFIX application. Such an RFC 235 should contain discussion of the new application, the Information 236 Element definitions as in Section 4, as well as suggested Templates 237 and examples of the use of those Templates within the new application 238 as in Section 8.2. Section 9 defines a compact textual Information 239 Element notation to be used in describing these suggested Templates 240 and/or the use of IPFIX Structured Data 241 [I-D.ietf-ipfix-structured-data] within the new application. 243 4. Defining new Information Elements 245 In many cases, a new application will require nothing more than a new 246 Information Element or set of Information Elements to be exportable 247 using IPFIX. An Information Element meeting the following criteria, 248 as evaluated by appointed IPFIX experts, is eligible for inclusion in 249 the Information Element registry: 251 o The Information Element MUST be sufficiently unique within the 252 registry. A proposed Information Elements which is a substantial 253 duplicate of an exiting Information Element is to be represented 254 using the existing Element. 256 o The Information Element SHOULD contain minimal internal structure; 257 complex information should be represented with multiple simple 258 Information Elements to be exported in parallel, as in 259 Section 4.5. 261 o The Information Element SHOULD be generally applicable to the 262 application at hand, which SHOULD be of general interest to the 263 community. Information Elements representing information about 264 proprietary or nonstandard applications SHOULD be represented 265 using enterprise-specific Information Elements as detailed in 266 section 6.2 of [RFC5101]. 268 The definition of new Information Elements requires a descriptive 269 name, a specification of the data type as one from the IPFIX Data 270 Type Registry, and a human-readable description written in English. 271 This section provides guidelines on each of these components of an 272 Information Element definition, referring to existing documentation 273 such as [RFC5102] as appropriate. 275 4.1. Information Element naming 277 Information Element Names should be defined in accordance with 278 section 2.3 of [RFC5102]; the most important naming conventions are 279 repeated here for convenience. 281 o Names of Information Elements should be descriptive. 283 o Names of Information Elements MUST be unique within the IPFIX 284 information model. 286 o Names of Information Elements start with non-capitalized letters. 288 o Composed names use capital letters for the first letter of each 289 component (except for the first one). All other letters are non- 290 capitalized, even for acronyms. Exceptions are made for acronyms 291 containing non-capitalized letter, such as 'IPv4' and 'IPv6'. 292 Examples are sourceMacAddress and destinationIPv4Address. 294 In addition, new Information Elements pertaining to a specific 295 protocol SHOULD name the protocol in the first word in order to ease 296 searching by name (e.g. "sipMethod" for a SIP method, as would be 297 used in a logging format for SIP based on IPFIX). Similarly, new 298 Information Elements pertaining to a specific application SHOULD name 299 the application in the first word. 301 4.2. Information Element data types 303 IPFIX provides a set of data types covering most primitives used in 304 network measurement and management applications. The most 305 appropriate data type should be chosen for the Information Element 306 type, out of the IPFIX informationElementDataTypes subregistry at 307 [iana-ipfix-assignments]. 309 Because IPFIX provides reduced-length encoding for Information 310 Elements, unless an integral Information Element is derived from a 311 fixed-width field in a measured protocol (e.g., tcpSequenceNumber, 312 which is an unsigned32), it should be defined with the maximum 313 possible width, generally signed64 or unsigned64. Applications can 314 then choose to use reduced-size encoding as defined in Section 6.2 of 315 [RFC5101] in cases where fewer than 2^64 values are necessary. 317 Information Elements representing time values should be exported with 318 appropriate precision. For example, a Information Element for a time 319 measured at second-level precision should be defined as having a 320 dateTimeSeconds data type, instead of dateTimeMilliseconds. 322 The type of an Information Element MUST match the type of the data it 323 represents. More specifically, information that could be represented 324 as a String, but which better matches one of the other data types 325 (e.g. an integral type for a number or enumerated type, an address 326 type for an address) MUST be represented by the best-matching type, 327 even if the data was represented using a different type in the source 328 (i.e., an IPFIX application that exports Options Template Records 329 mapping IP addresses to additional information about each host from 330 an external database MUST use Information Elements of an address type 331 to represent the addresses, even if the source database represented 332 these as strings.) 334 This document does NOT cover the addition of new Data Types or Data 335 Type Semantics to the IPFIX Protocol. As such changes have important 336 interoperability considerations and require implementation on both 337 Collecting and Exporting Processes, they require a Standards Action 338 as per [RFC5610]. However, note that the set of primitive types 339 provided by IPFIX are applicable to most any appropriate application, 340 so extending the type system is generally not necessary. 342 4.3. Information Element numbering 344 In general, when adding newly registered Information Elements to the 345 registry, IANA SHOULD assign the lowest available Information Element 346 identifier (the value column in [iana-ipfix-assignments] in the range 347 128-32767, noting that prior noncontiguous allocation may lead to 348 unassigned Information Elements with lower Information Element 349 identifiers than some presently assigned Information Elements. This 350 is the case with the PSAMP Information Model [RFC5477], which 351 assigned a block of Information Elements identifiers starting at 300. 353 Information Element identifiers in the range 1-128 MUST NOT be 354 assigned unless the Information Element is compatible with the 355 NetFlow v9 protocol as described in [RFC3954]. Such Information 356 Elements may ONLY be requested by a NetFlow v9 expert, to be 357 designated by the IESG to consult with IANA on NetFlow v9 358 compatibility with IPFIX. 360 4.4. Ancillary Information Element properties 362 Information Elements to which special semantics apply SHOULD define 363 these semantics with one of the values in the Information Element 364 Semantics registry, as described in Section 3.2 of [RFC5102], subject 365 to the restrictions given in Section 3.10 of [RFC5610]; essentially, 366 the semantics and the type must be consistent. 368 When defining Information Elements representing a dimensioned 369 quantity or entity count, the units of that quantity SHOULD be 370 defined in the units field. This field takes its values from the 371 IANA Information Element Units registry. If an Information Element 372 expresses a quantity in units not yet in this registry, then the unit 373 must be added to the Units registry at the same time the Information 374 Element is added to the Information Element registry. 376 Additionally, when the range of values an Information Element can 377 take is smaller than the range implied by its data type, the range 378 SHOULD be defined within the Information Element registry. 380 4.5. Internal structure in Information Elements 382 The definition of Information Elements with internal structure with 383 the structure defined in the Description field is discouraged, except 384 in the following cases: 386 o The Information Element is a direct copy of a structured entity in 387 a measured protocol (e.g. the tcpControlBits Information Element 388 for the flags byte from the TCP header) 390 o The Information Element represents a section of a packet of 391 protocol entity, in raw form as captured from the wire (e.g. the 392 mplsLabelStackSection Information Element for the MPLS label 393 stack) 395 o The Information Element represents a set of flags which are 396 tightly semantically related, where representing the flags as 397 separate one-byte booleans would be inefficient, and which should 398 always appear together in a data record (e.g., the 399 anonymizationFlags Information Element for specifying optional 400 features of anonymization techniques) 402 In other cases, candidate Information Elements with internal 403 structure SHOULD be decomposed into multiple primitive Information 404 Elements to be used in parallel. For more complicated semantics, 405 where the structure is not identical from Data Record to Data Record, 406 or where there is semantic dependency between multiple decomposed 407 primitive Information Elements, use the IPFIX Structured Data 408 [I-D.ietf-ipfix-structured-data] extension instead. 410 As an example of information element decomposition, consider an 411 application-level identifier called an "endpoint", which represents a 412 {host, port, protocol} tuple. Instead of allocating an opaque, 413 structured "source endpoint" Information Element, the source endpoint 414 should be represented by three separate Information Elements: "source 415 address", "source port", "transport protocol". In this example, the 416 required information elements already exist in the Information 417 Element registry: sourceIPv4Address or sourceIPv6Address, 418 sourceTransportPort, protocolIdentifier. Indeed, as well as being 419 good practice, this normalization down to non-structured Information 420 Elements also increases opportunities for reuse as in Section 6.1. 422 The decomposition of data with internal structure SHOULD avoid the 423 definition of Information Elements with a meaning too specific to be 424 generally useful, or that would result in either the export of 425 meaningless data or a multitude of templates to handle different 426 multiplicities. More information on multiplicities is given in the 427 following section. 429 4.6. Information Element multiplicity 431 Some Information Elements may represent information with a 432 multiplicity other than one; i.e., items that may occur multiple 433 times within the data to be represented in a single IPFIX record. In 434 this case, there are several options, depending on the circumstances: 436 o As specified in section 8 of [RFC5101]: "if an Information Element 437 is required more than once in a Template, the different 438 occurrences of this Information Element SHOULD follow the logical 439 order of their treatments by the Metering Process." In other 440 words, in cases where the items have a natural order (e.g., the 441 order in which they occur in the packet), and the multiplicity is 442 the same for each record, the information can be modeled by 443 containing multiple instances of the Information Element 444 representing a single item within the Template Record describing 445 the Data Records. 447 o In cases where the items have a variable multiplicity, a basicList 448 of the Information Element representing a single item can be used 449 as in the IPFIX Structured Data [I-D.ietf-ipfix-structured-data] 450 extension. 452 o If the multiple-item structure is taken directly from bytes 453 observed on the wire by the Metering Process or otherwise taken 454 from the application being measured, the multiple-item structure 455 can be exported as a variable-length octetArray Information 456 Element holding the raw content. 458 Specifically, new Information Element SHOULD NOT encode any 459 multiplicity or ordinality information into the definition of the 460 Information Element itself. 462 4.7. Enumerated Values and Subregistries 464 When defining an Information Element that takes an enumerated value 465 from a set of values which may change in the future, this enumeration 466 MUST be defined by an IANA registry or subregistry. For situations 467 where an existing registry defines the enumeration (e.g., the IANA 468 Protocol Numbers registry for the protocolIdentifier Information 469 Element), that registry MUST be used. Otherwise, a new IPFIX 470 subregistry must be defined for the enumerated value, to be modified 471 subject to Expert Review [RFC5226]. 473 4.8. Reversibility as per RFC 5103 475 [RFC5103] defines a method for exporting bidirectional flows using a 476 special Private Enterprise Number to define reverse-direction 477 variants of IANA Information Elements, and a set of criteria for 478 determining whether an Information Element may be reversed using this 479 method. Since almost all Information Elements are reversible, 480 [RFC5103] enumerates those which Information Elements which were 481 defined at the time of its publication which are NOT reversible. 483 New non-reversible Information Elements SHOULD contain a note in the 484 description stating that they are not reversible. 486 4.9. Promotion of Enterprise-Specific Information Elements 488 Some Information Elements may start their lifecycle outside the IANA 489 registry as enterprise-specific Information Elements scoped to a 490 Private Enterprise Number. One stated goal of enterprise-specific 491 Information Elements is pre-standards product delivery and 492 experimentation; should these experiments be successful and the 493 Information Elements generally useful, these SHOULD subsequently 494 registered with IANA. 496 In order to support transition from experimental registration to IANA 497 registration, the IANA registry provides an optional "enterprise- 498 specific IE reference" column for each Information Element. In cases 499 of promoted enterprise-specific Information Elements, this column in 500 the registry SHOULD contain the private enterprise and Information 501 Element numbers of the enterprise-specific version of the Information 502 Element. 504 4.10. Avoiding Bad Ideas in Information Element Design 506 In general, the existence of a similarly-defined Information Element 507 in the IANA registry sets a precedent which may be followed to 508 determine whether a given proposed Information Element "fits" within 509 the registry. Indeed, the rules specified by this document could be 510 interpreted to mean "make new Information Elements that look like 511 existing Information Elements". However, for reasons of history, 512 there are several Information Elements within the IANA registry which 513 do not follow best practices in Information Element design, and 514 should be explicitly ignored when looking for guidance as to whether 515 a new Information Element should be added. 517 Before registering a new Information Element, it must be determined 518 that it would be sufficiently unique within the registry. This 519 evaluation has not always been done in the past, and the existence of 520 the Information Elements defined without this evaluation should not 521 be taken as an example that such Information Element definition 522 practices should be followed in the future. Specific examples of 523 such Information Elements include initiatorOctets and responderOctets 524 (which duplicate octetDeltaCount and its reverse per [RFC5103]) and 525 initiatorPackets and responderPackets (the same, for 526 packetDeltaCount). 528 As mentioned in Section 4.2, the type of an Information Element 529 SHOULD match the type of data the Information Element represents. An 530 example of how not to do this is presented by the p2pTechnology, 531 tunnelTechnology, and encryptedTechnology Information Elements: these 532 represent a three-state enumeration using a String. The example set 533 by these Information Elements SHOULD NOT be followed in the 534 definition of new Information Elements. 536 As mentioned in Section 4.6, an Information Element definition SHOULD 537 NOT include any ordinality or multiplicity information. The only 538 example of this within the IANA registry the following list of 539 assigned IPFIX Information Elements: mplsTopLabelStackSection, 540 mplsLabelStackSection2, mplsLabelStackSection3, 541 mplsLabelStackSection4, mplsLabelStackSection5, 542 mplsLabelStackSection6 mplsLabelStackSection7, 543 mplsLabelStackSection8, mplsLabelStackSection9, and 544 mplsLabelStackSection10. The only distinction between those almost- 545 identical Information Elements is the position within the MPLS stack. 546 This Information Element design pattern met an early requirement of 547 the definition of IPFIX which was not carried forward into the final 548 specification -- namely, that no semantic dependency was allowed 549 between Information Elements in the same Record -- and as such SHOULD 550 NOT be followed in the definition of new Information Elements. In 551 this case, since the size of the MPLS stack will vary from flow to 552 flow, it should be exported using IPFIX Structured Data 553 [I-D.ietf-ipfix-structured-data] where supported, as a basicList of 554 MPLS label entries, or as a raw MPLS label stack using the variable- 555 length mplsLabelStackSection Information Element. 557 5. The Information Element Lifecycle 559 Once an Information Element or set of Information Elements has been 560 identified for a given application, Information Element 561 specifications in accordance with Section 4 are submitted to IANA to 562 follow the IE-DOCTORS process, as defined below. This process is 563 also used for other changes to the registry, such as deprecation or 564 revision, as described later in this section. 566 5.1. The IE-DOCTORS process 568 Requests to change the IANA Information Element registry or a linked 569 subregistry are submitted to IANA, which forwards the request to a 570 designated group of experts (IE-DOCTORS) appointed by the IETF 571 Operations Area Directors. This group of experts reviews the request 572 for compliance with this document, compliance with other applicable 573 IPFIX-related RFCs, and consistency with the currently defined set of 574 Information Elements. 576 IE-DOCTORS reviewers should endeavor to complete referred reviews in 577 a timely manner. If the request is acceptable, the IE-DOCTORS 578 signify their approval to IANA, which changes the IANA Information 579 Element registry. If the request is not acceptable, the IE-DOCTORS 580 can coordinate with the requestor to change the request to be 581 compliant. The IE-DOCTORS may also choose in exceptional 582 circumstances to reject clearly frivolous or inappropriate change 583 requests outright. 585 5.2. Revising Information Elements 587 The Information Element status field in the Information Element 588 Registry is defined in [RFC5102] to allow Information Elements to be 589 'current', 'deprecated' or 'obsolete'. No Information Elements are 590 as of this writing deprecated or obsolete, and [RFC5102] does not 591 define any policy for using them. Additionally, no policy is defined 592 for revising Information Element registry entries or addressing 593 errors therein. To be certain, changes and deprecations within the 594 Information Element registry are not encouraged, and should be 595 avoided to the extent possible. However, in recognition that change 596 is inevitable, this section is intended to remedy this situation. 598 The primary requirement in the definition of a policy for managing 599 changes to existing Information Elements is avoidance of 600 interoperability problems; IPFIX experts appointed to review changes 601 to the Information Element Registry MUST work to maintain 602 interoperability above all else. Changes to Information Elements 603 already in use may only be done in an interoperable way; necessary 604 changes which cannot be done in a way to allow interoperability with 605 unchanged implementations MUST result in deprecation. 607 A change to an Information Element is held to be interoperable only 608 when: 610 o it involves the correction of an error which is obviously only 611 editorial; or 613 o it corrects an ambiguity in the Information Element's definition, 614 which itself leads to non-interoperability (e.g., a prior change 615 to ipv6ExtensionHeaders); or 617 o it expands the Information Element's data type without changing 618 how it is represented (e.g., changing unsigned32 to unsigned64, as 619 with a prior change to selectorId); or 621 o it defines a previously undefined or reserved enumerated value, or 622 one or more previously reserved bits in an Information Element 623 with flag semantics; or 625 o it expands the set of permissible values in the Information 626 Element's range; or 628 o it harmonizes with an external reference which was itself 629 corrected. 631 A non-interoperable Information Element change may also be made if it 632 can be reasonably assumed in the eyes of the appointed experts that 633 no unchanged implementation of the Information Element exists; this 634 can be held to happen if a non-interoperable change to an Information 635 Element defined shortly before is proposed to the IPFIX mailing list 636 by the original proposer of the Information Element, and no objection 637 is raised within a reasonable amount of time, to be defined by the 638 expert reviewers. 640 If a change is permissible, it is sent to IANA, which passes it to 641 the appointed experts for review; if there is no objection to the 642 change from any appointed expert, IANA makes the change in the 643 Information Element Registry. The requestor of the change is 644 appended to the Requestor in the registry. 646 Each Information Element in the IANA registry has a revision number, 647 starting at zero. Each change to an Information Element following 648 this process increments the revision number by one. Since any 649 revision must be interoperable according to the criteria above, there 650 is no need for the IANA registry to store information about old 651 revisions. 653 5.3. Deprecating Information Elements 655 Changes that are not permissible by these criteria may only be 656 handled by deprecation. An Information Element MAY be deprecated and 657 replaced when: 659 o the Information Element definition has an error or shortcoming 660 which cannot be permissibly changed as above; or 662 o the deprecation harmonizes with an external reference which was 663 itself deprecated through that reference's accepted deprecation 664 method; or 666 o changes in the IPFIX Protocol or its extensions, or in community 667 understanding thereof, allow the information represented by the 668 Information Element to be represented in a more efficient or 669 convenient way. Deprecation in this circumstance additionally 670 requires the assent of the IPFIX Working Group, and should be 671 specified in the Internet Draft(s) defining the protocol change. 673 A request for deprecation is sent to IANA, which passes it to the IE- 674 DOCTORS for review, as above. When deprecating an Information 675 Element, the Information Element description MUST be updated to 676 explain the deprecation, as well as to refer to any new Information 677 Elements created to replace the deprecated Information Element. The 678 revision number of an Information Element is incremented upon 679 deprecation. 681 Deprecated Information Elements SHOULD continue to be supported by 682 Collecting Processes, but SHOULD NOT be exported by Exporting 683 Processes. The use of deprecated Information Elements SHOULD result 684 in a log entry or human-readable warning at the Exporting and 685 Collecting Processes. After a period of time determined in the eyes 686 of the IE-DOCTORS experts to be reasonable in order to allow deployed 687 Exporting Processes to be updated to account for the deprecation, a 688 deprecated Information Element may be made obsolete. Obsolete 689 Information Elements MUST NOT be supported by either Exporting or 690 Collecting Processes. The receipt of obsolete Information Elements 691 SHOULD be logged by the Collecting Process. 693 Names of deprecated Information Elements MUST NOT be reused. Names 694 of obsolete Information Elements MAY be reused, but this is NOT 695 RECOMMENDED, as it may cause confusion among users. 697 5.4. Versioning the entire IANA Registry 699 Consider a typical Collector implementation, which regularly 700 downloads the entire registry in order to be compliant with the 701 latest of set of supported IEs. While a registry revision number 702 might seems advantageous for the Collector at first glance (avoiding 703 the one by one comparison of all IE revisions), it is not necessary, 704 as the IPFIX IANA registry specifies the date at which the registry 705 was last updated in the "Last Updated" field. For purposes of 706 identifying the latest set of Information Element versions specified 707 in registry, the last revision date of the Information Element 708 registry (available in the registry XML source, or from the Last- 709 Modified: header of [iana-ipfix-assignments]) SHOULD be used. 711 6. When not to define new Information Elements 713 Also important in defining new applications is avoiding redundancy 714 and clutter in the Information Element registry. Here we provide 715 guidelines for reuse of existing Information Elements, as well as 716 guidelines on using enterprise-specific Information Elements instead 717 of adding Information Elements in the registry. 719 6.1. Maximizing reuse of existing Information Elements 721 Whenever possible, new applications should prefer usage of existing 722 IPFIX Information Elements to the creation of new Information 723 Elements. IPFIX already provides Information Elements for every 724 common Layer 4 and Layer 3 packet header field in the IETF protocol 725 suite, basic Layer 2 information, basic counters, timestamps and time 726 ranges, and so on. When defining a new Information Element similar 727 to an existing one, reviewers shall ensure that the existing one is 728 not applicable. 730 Note that this guideline to maximize reuse does not imply that an 731 Information Element that represents the same information from a 732 packet as a existing Information Element should not be added to the 733 registry. For example, consider the ipClassOfService (Element ID 5), 734 ipDiffServCodePoint (Element ID 98), and ipPrecedence (Element ID 735 196) Information Elements. These all represent subsets of the same 736 field in an IP version 4 packet header, but different uses of these 737 bits. The representation in one or another of these Information 738 Elements contains information in itself as to how the bits were 739 interpreted by the Metering Process. 741 On the other hand, simply changing the context in which an 742 Information Element will be used is insufficient reason for the 743 definition of a new Information Element. For example, an extension 744 of IPFIX to log detailed information about HTTP transactions 745 alongside network-level information should not define 746 httpClientAddress and httpServerAddress Information Elements, 747 preferring instead the use of sourceIPv[46]Address and 748 destinationIPv[46]Address. 750 Applications dealing with bidirectional interactions should use 751 Bidirectional Flow Support for IPFIX [RFC5103] to represent these 752 interactions. 754 Specifically, existing timestamp and time range Information Elements 755 should be reused for any situation requiring simple time stamping of 756 an event: for single observations, the observationTime* Information 757 Elements from PSAMP are provided, and for events with a duration, the 758 flowStart* and flowEnd* Information Elements suffice. This 759 arrangement allows minimal generic time handling by existing 760 Collecting Processes and analysis workflows. New timestamp 761 Information Elements should ONLY be defined for semantically distinct 762 timing information (e.g., an IPFIX-exported record containing 763 information about an event to be scheduled in the future). 765 In all cases the use of absolute timestamp Information Elements (e.g. 766 flowStartMilliseconds) is RECOMMENDED, as these Information Elements 767 allow for maximum flexibility in processing with minimal overhead. 768 Timestamps based on the export time header in the enclosing IPFIX 769 Message (e.g. flowStartTimeDeltaMicroseconds) MAY be used if high- 770 precision timing is important, export bandwidth or storage space is 771 limited, timestamps comprise a relatively large fraction of record 772 size, and the application naturally groups records into IPFIX 773 Messages. Timestamps based on information which must be exported in 774 a separate Data Record defined by an Options Template (e.g. 775 flowStartSysUpTime) MAY be used only in the context of an existing 776 practice of using runtime-defined epochs for the given application. 777 New applications SHOULD avoid these structures when possible. 779 6.2. Applying enterprise-specific Information Elements 781 IPFIX provides a mechanism for defining enterprise-specific 782 Infomation Elements, as in Section 3.2 of [RFC5101]. These are 783 scoped to a vendor's or organization's Structure of Management 784 Information (SMI) Private Enterprise Number, and are under complete 785 control of the organization assigning them. 787 For situations in which interoperability is unimportant, new 788 information SHOULD be exported using enterprise-specific Information 789 Elements instead of adding new Information Elements to the registry. 790 These situations include: 792 o export of implementation-specific information, or 794 o export of information derived in a commercially-sensitive or 795 proprietary method, or 797 o export of information or meta-information specific to a 798 commercially-sensitive or proprietary application. 800 While work within the IETF generally does not fall into these 801 categories, enterprise-specific Information Elements are also useful 802 for pre-standardization testing of a new IPFIX application. While 803 performing initial development and interoperability testing of a new 804 application, the Information Elements used by the application SHOULD 805 NOT be submitted to IANA for inclusion in the registry. Instead, 806 these experimental Information Elements SHOULD be represented as 807 enterprise-specific until their definitions are finalized, then 808 transitioned from enterprise-specific to IANA-defined upon 809 finalization. To support this transition, the IANA registry provides 810 an experimental IE reference as defined in Section 4.9. 812 7. Applying IPFIX to non-Flow Applications 814 At the core of IPFIX is its definition of a Flow, a set of packets 815 sharing some common properties crossing an observation point within a 816 certain time window. However, the reliance on this definition does 817 not preclude the application of IPFIX to domains which are not 818 obviously handling flow data according to it. Most network 819 management data collection tasks, those to which IPFIX is most 820 applicable, have at their core the movement of packets from one place 821 to another; by a liberal interpretation of the common properties 822 defining the flow, then, almost any event handled by these can be 823 held to concern data records conforming to the IPFIX definition of a 824 Flow. 826 Non-flow information defining associations or key-value pairs, on the 827 other hand, are defined by IPFIX Options Templates. Here, the 828 Information Elements within an Options Template Record are divided 829 into Scope Information Elements which define the key, and non-scope 830 Informatin Elements which define the values associated with that key. 831 Unlike Flows, Data Records defined by Options Template are not 832 necessarily scoped in time; these Data Records are generally held to 833 be in effect until a new set of values for a specific set of keys is 834 exported. While this mechanism is often used by IPFIX to export 835 metadata about the collection infrastructure, it is applicable to any 836 association information. 838 An IPFIX application can mix Data Records described either type of 839 template in an IPFIX Message or Message stream, and exploit 840 relationships among the Flow Keys, values, and Scopes to create 841 interrelated data structures. See [RFC5473] for an example 842 application of this. 844 8. Writing Internet-Drafts for IPFIX Applications 846 When a new application is complex enough to require additional 847 clarification or specification as to the use of the defined 848 Information Elements, this may be given in an Internet-Draft. 849 Internet-Drafts for new IPFIX applications are best submitted to a 850 Working Group with expertise in the area of the new application, or 851 as independent submissions. 853 When defining new Information Elements in an Internet-Draft, the 854 Internet-Draft SHOULD contain a section (or subsection) for each 855 Information Element, which contains the attributes in Section 4 in 856 human-readable form. An example subsection is given below. These 857 Information Element descriptions SHOULD NOT assign Information 858 Element numbers, instead using placeholder identifiers for these 859 numbers (e.g. "AAA", "BBB", "CCC", or "TBD1", "TBD2", "TBD3") and a 860 note to IANA in the IANA Considerations section to replace those 861 placeholders in the document with Information Element numbers when 862 the numbers are assigned. The use of these placeholder definitions 863 allows references to the numbers in e.g. box-and-line diagrams or 864 template definitions as in Section 9. 866 8.1. Example Information Element Definition 868 This is an example of an Information Element definition which would 869 appear in an Internet-Draft. The name appears in the section title. 871 Description: Description goes here. 873 Data Type: Data type goes here; obligatory 875 Data Type Semantics: Data type semantics, if any, go here; optional 877 Units: Units, if any, go here; optional 879 Range: Range, if not implied by the data type, goes here; optional 881 References: References to other RFCs or documents outside the IETF, 882 in which additional information is given, or which are referenced 883 by the description, go here; optional 885 ElementId: TBD1 887 8.2. Defining Recommended Templates 889 New IPFIX applications SHOULD NOT, in the general case, define fixed 890 templates for export, as this throws away much of the flexibility 891 afforded by IPFIX. However, fixed template export is permissible in 892 the case that the export implementation must operate in a resource 893 constrained environment, and/or that the application is replacing an 894 existing fixed-format binary export format in a maximally compatible 895 way. In any case, Collecting Processes for such applications SHOULD 896 support reordered Templates or Templates with additional Information 897 Elements. 899 An Internet-Draft clarifying the use of new Information Elements 900 SHOULD include any recommended Template or Options Template Records 901 necessary for supporting the application, as well as examples of 902 records exported using these Template Records. In defining these 903 Template Records, such Internet-Drafts SHOULD mention, subject to 904 rare exceptions as above: 906 o that the order of Information Elements within a Template is not 907 significant; 909 o that Templates on the wire for the application may also contain 910 additional Information Elements beyond those specified in the 911 recommended Template; 913 o that a stream of IPFIX Messages supporting the application may 914 also contain Data Records not described by the recommended 915 Templates; and 917 o that any reader of IPFIX Messages supporting the application MUST 918 accept these conditions. 920 Definitions of recommended Template Records for flow-like 921 information, where the Flow Key is well-defined, SHOULD indicate 922 which of the Information Elements in the recommended Template are 923 Flow Keys. 925 Recommended Templates are defined, for example, in [RFC5476] for 926 PSAMP packet reports (section 6.4) and extended packet reports 927 (section 6.5). Recommended Options Templates are defined extensively 928 throughout the IPFIX documents, including in the protocol document 929 itself [RFC5101] for exporting export statistics; in the file format 930 [RFC5655] for exporting file metadata; and in Mediator intermediate 931 process definitions such as [I-D.ietf-ipfix-anon] for intermediate 932 process metadata. The discussion in these examples is a good model 933 for recommended template definitions. 935 9. A Textual Format for Specifying Information Elements and Templates 937 The examples given above are all expressed using bitmap diagrams of 938 the respective Templates. These are illustrative of the wire 939 representation of simple Templates, but not particularly readable for 940 more complicated recommended Templates, provide no support for rapid 941 implementation of new Templates, and do not adequately convey the 942 optional nature of ordering and additional Information Elements as 943 above. Therefore, we define a RECOMMENDED textual format for 944 specifying Information Elements and Templates in Internet-Drafts in 945 this section. 947 Here we define a simple textual syntax for describing IPFIX 948 Information Elements and IPFIX Templates, with human readability, 949 human writability, compactness, and ease of parser/generator 950 implementation without requiring external XML support as design 951 goals. It is intended both for use in human communication (e.g., in 952 new Internet-Drafts containing higher-level descriptions of IPFIX 953 Templates, or describing sets of new IPFIX Information Elements for 954 supporting new applications of the protocol) as well as at runtime by 955 IPFIX implementations. 957 9.1. Information Element Specifiers 959 The basis of this format is the textual Information Element 960 Specifier, or IESpec. An IESpec contains each of the four important 961 aspects of an Information Element: its name, its number, its type, 962 and its size, separated by simple markup based on various types of 963 brackets. Fully-qualified IESpecs may be used to specify existing or 964 new Information Elements within an Information Model, while either 965 fully-qualified or partial IESpecs may be used to define fields in a 966 Template. 968 Bare words are used for Information Element names, and each aspect of 969 information associated with an Information Element is associated with 970 a type of brackets: 972 o () parentheses for Information Element numbers, 974 o <> angles for Information Element data types, and 976 o [] square brackets for Information Element sizes. 978 o {} curly braces contain an optional space-separated list of 979 context identifiers to be associated with an Information Element, 980 as described in more detail in Section 9.2 982 The symbol + is reserved for Information Element nesting within 983 structured data elements; these are described in and Section 9.3, 984 respectively. 986 Whitespace in IESpecs is insignificant; spaces can be added after 987 each element in order, e.g., to align columns for better readability. 989 The basic form of a fully-qualified IESpec for an IANA-registered 990 Information Element is as follows: 992 name(number)[size] 994 where 'name' is the name of the Information Element in UTF-8, 995 'number' is the Information Element as a decimal integer, 'type' is 996 the name of the data type as in the IANA informationElementDataTypes 997 registry, and 'size' is the length of the Information Element in 998 octets as a decimal integer, where 65535 or the string 'v' signifies 999 a variable-length Information Element. [size] may be omitted; in this 1000 case, the data type's native or default size is assumed. 1002 The basic form of a fully-qualified IESpec for an enterprise-specific 1003 Information Element is as follows: 1005 name(pen/number)[size] 1007 where 'pen' is the Private Enterprise Number as a decimal integer. 1009 A fully-qualified IESpec is intended to express enough information 1010 about an Information Element to decode and display Data Records 1011 defined by Templates containing that Information Element. Range, 1012 unit, semantic, and description information, as in [RFC5610], is not 1013 supported by this syntax. 1015 Example fully-qualified IESpecs follow: 1017 octetDeltaCount(1)[8] 1019 octetDeltaCount(1) (unsigned64 is natively 8 octets 1020 long) 1022 sourceIPv4Address(8) 1024 wlanSSID(146)[v] 1026 sipRequestURI(35566/403)[65535] 1028 A partial IESpec is any IESpec that is not fully-qualified; these are 1029 useful when defining templates. A partial IESpec is assumed to take 1030 missing values from its canonical definition, for example, the IANA 1031 registry. At minimum, a partial IESpec must contain a name, or a 1032 number. Any name, number, or type information given with a partial 1033 IESpec must match the values given in the Information Model; however, 1034 size information in a partial IESpec overrides size information in 1035 the Information Model; in this way, IESpecs can be used to express 1036 reduced-length encoding for Information Elements. 1038 Example partial IESpecs follow: 1040 o octetDeltaCount 1042 o octetDeltaCount[4] (reduced-length encoding) 1044 o (1) 1046 o (1)[4] (reduced length encoding; note that this is exactly 1047 equivalent to an Information Element specifier in a Template) 1049 9.2. Specifying Templates 1051 A Template can then be defined simply as an ordered, newline- 1052 separated sequence of IESpecs. IESpecs in example Templates 1053 illustrating a new application of IPFIX SHOULD be fully-qualified. 1054 Flow Keys may be optionally annotated by appending the {key} context 1055 to the end of each Flow Key specifier. A template counting packets 1056 and octets per five-tuple with millisecond precision in IESpec syntax 1057 is shown below. 1059 flowStartMilliseconds(152)[8] 1060 flowEndMilliseconds(153)[8] 1061 octetDeltaCount(1)[8] 1062 packetDeltaCount(2)[8] 1063 sourceIPv4Address(8)[4]{key} 1064 destinationIPv4Address(12)[4]{key} 1065 sourceTransportPort(7)[2]{key} 1066 destinationTransportPort(11)[2]{key} 1067 protocolIdentifier(4)[1]{key} 1069 An Options Template is specified similarly. Scope is specified 1070 appending the {scope} context to the end of each IESpec for a Scope 1071 IE. Due to the way Information Elements are represented in Options 1072 Templates, all {scope} IESpecs must appear before any non-scope 1073 IESpec. The Flow Key Options Template defined in section 4.4 of 1074 [RFC5101] in IESpec syntax is shown below: 1076 templateId(145)[2]{scope} 1077 flowKeyIndicator(173)[8] 1079 9.3. Specifying IPFIX Structured Data 1081 IESpecs can also be used to illustrate the structure of the 1082 information exported using the IPFIX Structured Data extension 1083 [I-D.ietf-ipfix-structured-data]. Here, the semantics of the 1084 structured data elements are specified using contexts, and the 1085 information elements within each structured data element follow the 1086 structured data element, prefixed with + to show they are contained 1087 therein. Arbitrary nesting of structured data elements is possible 1088 by using multiple + signs in the prefix. For example, a basic list 1089 of IP addresses with "one or more" semantics would be expressed using 1090 parially qualified IESpecs as follows: 1092 basicList{oneOrMoreOf} 1093 +sourceIPv4Address(8)[4] 1095 And an example subTemplateList itself containing a basicList is shown 1096 below: 1098 subTemplateList{allOf} 1099 +basicList{oneOrMoreOf} 1100 ++sourceIPv4Address(8)[4] 1101 +destinationIPv4Address(12)[4] 1103 This describes a subTemplateMultilist containing all of the expressed 1104 set of source-destination pairs, where the source address itself 1105 could be one of any number in a basicList (e.g., in the case of SCTP 1106 multihoming). 1108 The contexts associable with structured data Information Elements are 1109 the semantics, as defined in section 4.4 of 1110 [I-D.ietf-ipfix-structured-data]; a structured data Information 1111 Element without any context is taken to have undefined semantics. 1112 More information on the application of structured data is available 1113 in [I-D.ietf-ipfix-structured-data]. 1115 10. Security Considerations 1117 The security aspects of new Information Elements must be considered 1118 in order not to give a potential attacker too much information. For 1119 example, the "A Framework for Packet Selection and Reporting" 1120 [RFC5474] concluded in section 12.3.2 that the hash functions private 1121 parameters should not exported within IPFIX. 1123 If some security considerations are specific to an Information 1124 Element, they MUST be mentioned in the Information Element 1125 description. For example, the ipHeaderPacketSection in the IPFIX 1126 registry mentions: "This Information Element, which may have a 1127 variable length, carries a series of octets from the start of the IP 1128 header of a sampled packet. With sufficient length, this element 1129 also reports octets from the IP payload, subject to [RFC2804]. See 1130 the Security Considerations section." 1132 These security considerations MAY also be stressed in an accompanying 1133 Internet-Draft, as in Section 8. For example, the "Packet Sampling 1134 (PSAMP) Protocols Specification" [RFC5476] specifies: "In the basic 1135 Packet Report, a PSAMP Device exports some number of contiguous bytes 1136 from the start of the packet, including the packet header (which 1137 includes link layer, network layer and other encapsulation headers) 1138 and some subsequent bytes of the packet payload. The PSAMP Device 1139 SHOULD NOT export the full payload of conversations, as this would 1140 mean wiretapping [RFC2804]. The PSAMP Device MUST respect local 1141 privacy laws." 1143 11. IANA Considerations 1145 With respect to the management of the IPFIX Information Element 1146 registry and associated subregistries located at 1147 [iana-ipfix-assignments], this document defines a process for IANA in 1148 Section 5.1, and includes a set of guidelines for IANA for applying 1149 this process in Section 4, Section 5, and Section 6. 1151 In addition, in order to support more effective management of the 1152 Information Element lifecycle as defined in Section 5, it specifies 1153 the addition of three new columns for this registry: 1155 Revision: a serial revision number for each Information Element, 1156 beginning at 0 for all presently existing and newly created 1157 Information Elements. 1159 Date: the date at which the Information Element was created or last 1160 modified. 1162 Enterprise-specific reference: for Information Elements which where 1163 deployed as enterprise-specific Information Elements for 1164 experimentation and testing, and subsequently registered in the 1165 IANA registry, specifies the private enterprise number (PEN) and 1166 IE number of the equivalent experimental IE. 1168 12. Acknowledgements 1170 The authors would like to acknowledge the FP7 PRISM and DEMONS 1171 projects for their material support of this work. 1173 13. References 1175 13.1. Normative References 1177 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 1178 9", RFC 3954, October 2004. 1180 [RFC5101] Claise, B., "Specification of the IP Flow Information 1181 Export (IPFIX) Protocol for the Exchange of IP Traffic 1182 Flow Information", RFC 5101, January 2008. 1184 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1185 Meyer, "Information Model for IP Flow Information Export", 1186 RFC 5102, January 2008. 1188 [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export 1189 Using IP Flow Information Export (IPFIX)", RFC 5103, 1190 January 2008. 1192 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 1193 "Exporting Type Information for IP Flow Information Export 1194 (IPFIX) Information Elements", RFC 5610, July 2009. 1196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1197 Requirement Levels", BCP 14, RFC 2119, March 1997. 1199 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1200 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1201 May 2008. 1203 13.2. Informative References 1205 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 1206 May 2000. 1208 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1209 "Requirements for IP Flow Information Export (IPFIX)", 1210 RFC 3917, October 2004. 1212 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1213 Documents", BCP 111, RFC 4181, September 2005. 1215 [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. 1216 Aitken, "IP Flow Information Export (IPFIX) Implementation 1217 Guidelines", RFC 5153, April 2008. 1219 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1220 "Architecture for IP Flow Information Export", RFC 5470, 1221 March 2009. 1223 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP 1224 Flow Information Export (IPFIX) Testing", RFC 5471, 1225 March 2009. 1227 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 1228 Flow Information Export (IPFIX) Applicability", RFC 5472, 1229 March 2009. 1231 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy 1232 in IP Flow Information Export (IPFIX) and Packet Sampling 1233 (PSAMP) Reports", RFC 5473, March 2009. 1235 [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., 1236 Grossglauser, M., and J. Rexford, "A Framework for Packet 1237 Selection and Reporting", RFC 5474, March 2009. 1239 [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling 1240 (PSAMP) Protocol Specifications", RFC 5476, March 2009. 1242 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 1243 Carle, "Information Model for Packet Sampling Exports", 1244 RFC 5477, March 2009. 1246 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 1247 Wagner, "Specification of the IP Flow Information Export 1248 (IPFIX) File Format", RFC 5655, October 2009. 1250 [I-D.ietf-ipfix-structured-data] 1251 Claise, B., Dhandapani, G., Yates, S., and P. Aitken, 1252 "Export of Structured Data in IPFIX", 1253 draft-ietf-ipfix-structured-data-06 (work in progress), 1254 May 2011. 1256 [I-D.ietf-ipfix-anon] 1257 Boschi, E. and B. Trammell, "IP Flow Anonymization 1258 Support", draft-ietf-ipfix-anon-06 (work in progress), 1259 January 2011. 1261 [iana-ipfix-assignments] 1262 Internet Assigned Numbers Authority, "IP Flow Information 1263 Export Information Elements 1264 (http://www.iana.org/assignments/ipfix/ipfix.xml)". 1266 Authors' Addresses 1268 Brian Trammell 1269 Swiss Federal Institute of Technology Zurich 1270 Gloriastrasse 35 1271 8092 Zurich 1272 Switzerland 1274 Phone: +41 44 632 70 13 1275 Email: trammell@tik.ee.ethz.ch 1277 Benoit Claise 1278 Cisco Systems, Inc. 1279 De Kleetlaan 6a b1 1280 1831 Diagem 1281 Belgium 1283 Phone: +32 2 704 5622 1284 Email: bclaise@cisco.com