idnits 2.17.00 (12 Aug 2021) /tmp/idnits45744/draft-inacio-ipfix-penie-00.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 11 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** There are 6 instances of too long lines in the document, the longest one being 46 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 13, 2013) is 3288 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC2119' is defined on line 249, but no explicit reference was found in the text == Unused Reference: 'RFC5102' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC4234' is defined on line 264, but no explicit reference was found in the text == Unused Reference: '2223BIS' is defined on line 269, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group C. Inacio 3 Internet-Draft Carnegie Mellon University 4 Intended Status: Standards Track November 9, 2012 5 Expires May 13, 2013 7 Private Enterprise Information Elements Registry Exchange 8 10 Abstract 12 This extension to the IPFIX protocol is intended to provide a 13 mechanism for IPFIX exporters which export private information 14 elements to also transmit information to the collectors. The 15 mechanism is designed to be able to send a URI with information about 16 the private information elements via an options template. 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), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire in May 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Options Record Format . . . . . . . . . . . . . . . . . . . . . 4 57 3. Registry Design . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Registry Introduction . . . . . . . . . . . . . . . . . . . 6 59 3.2. Registry Informational Elements . . . . . . . . . . . . . . 6 60 3.3. Registry Formatting . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 99.0. To be removed . . . . . . . . . . . . . . . . . . . . . . 10 68 99.1. Formatting End of Page . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 The IPFIX protocol [RFC5101] defined a significant information 73 element set for a large number of relevant network activities. The 74 IPFIX protocol was also designed with the ability to extend its 75 information model both via a standards based mechanism, via an IANA 76 registry, to add elements of general interest, but also the ability 77 to add elements via private enterprise numbers to define elements of 78 limited interest. Beyond adding the ability to pass new information 79 elements, the IPFIX protocol is designed to allow collectors the 80 ability to skip information elements which cannot be comprehended. 82 IPFIX was extended in RFC 5610 IPFIX Semantic Type Information to 83 allow IPFIX send type semantic information about information 84 elements. This mechanism allows an IPFIX exporter to send type 85 semantic information along with a common name about an information 86 element to the collector. This allows information elements that the 87 collector would otherwise not be able to comprehend to provide much 88 more information. 90 The mechanism proposed here extends the Semantic Type Information in 91 two ways. First, it allows a more complex definition of information 92 to be presented, capturing the possible relationships contained 93 within the IPFIX Structured Data extension. The IPFIX Structured 94 Data extension, having completed after the Semantic Type Information, 95 is not covered in the Semantic Type Information. Secondly, by moving 96 the information element metadata out from the potentially resource 97 constrained IPFIX data channel, this extension allows a richer and 98 comprehensive set of metadata to be expressed. 100 2. Options Record Format 102 The mechanism used to transmit the URI information from the exporter 103 to the collector is an options template with a URI. The URI contains 104 a pointer which provides well formatted, as specified in section 3, 105 information about the semantic type information and description of 106 the private information elements. 108 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Set ID = 3 | Length = 14 | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Template ID = 257 | Field Count = | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Scope Field Count = |0| private ent. number 346 | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Field Length = 4 | PEN Registry URI XXX | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Field Length = 65536 | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 Figure 1: Example PENIE Template Definition 124 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Set ID = 257 | Length = 46 | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Private Enterprise Number | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Length = 39 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 133 | "http://tools.netsa.cert.org/yaf_pen.xml" | 134 + + 135 | | 136 + + 137 | | 138 + + 139 | | 140 + + 141 | | 142 + + 143 | | 144 + + 145 | | 146 + + 147 | | 148 + + 149 | | 150 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 2: Example PENIE Data Record 156 The options record allows for creating a URI reference for a private 157 enterprise number. It is important to note that more than one URI 158 per a single private enterprise number. The burden of resolving all 159 declared registries falls onto the collector to be able to decode all 160 information elements received from the exporters. 162 3. Registry Design 163 3.1. Registry Introduction 165 The registry design goals are to capture all the information that 166 IPFIX Type Information [RFC5610] provides about individual elements, 167 but to also present more metadata about both individual elements as 168 well as have the ability to provide more information about a 169 collection of elements. 171 3.2. Registry Informational Elements 173 The top level of a registry contains the following additional 174 elements: 175 o Registry ID - This is an ID that can be used by the creator of 176 the registry to be able to track the registry as a unique item. 178 o Version - Indicates the release version of the registry. 180 o Name - A common name that can be used to refer to the registry. 182 o Security Type - This is a new entry type that allows the 183 complete set of elements defined in the registry to be 184 contained within a security type class. By allowing the 185 collector to understand the security type, if present, of the 186 information elements a new class of actions may be taken by a 187 collector implementation. 189 o Policy Type - Similar to the security type, this new entry 190 allows the complete set of elements defined in the registry to 191 be contained within a policy type class. Again, similar to the 192 security type class, the collector may take new actions based 193 upon understanding the policy type of an information element. 195 o Canonical URI - This is the canonical URI to be able to locate 196 the authoritative version of the registry. 198 o Root EID - This defines the Private Enterprise ID for all 199 elements defined in the registry. 201 o Copyright - Optionally the copyright information for the 202 registry 204 o Contact - Contact information to be able to contact the 205 publisher of the registry. 207 o Directory - (I can't remember, but its a URI). 209 Each information element defined in the registry are as follows: 211 o ID - The information element ID. 213 o PEN - The private enterprise number. 215 o Data type - The data type of the element, as defined in RFC 216 5610. 218 o Semantics - The semantic of the element, as defined in RFC 5610. 220 o Units - The units of the element, as defined in RFC 5610. 222 o Description - The human readable (and hopefully understandable) 223 description of the element. 225 o MIME Path - An optional MIME path definition of the element. 227 3.3. Registry Formatting 229 XML or JSON or ???? format to be added here. 231 5. Security Considerations 233 There are no security considerations relevant to this document, 234 beyond the security considerations necessary in the IPFIX protocol 235 specification [RFC5101] and its successors. 237 6. IANA Considerations 239 IANA needs to create two registries with expert review: 241 Security types Policy types 243 and create a code point for a new information element. 245 6. References 247 6.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC5101] Claise, B., "Specification of the IP Flow Information 253 Export (IPFIX) Protocol for the Exchange of IP Traffic 254 Flow Information", RFC 5101, January 2008. 256 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and Meyer, 257 J., "Information Model for IP Flow Information Export", 258 RFC 5102, January 2008. 260 [RFC5610] Boschi, E., Trammell, B., Mark, L., and Zseby, T., 261 "Exporting Type Information for IP Flow Information Export 262 (IPFIX) Information Elements", RFC 5610, July 2009. 264 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 265 Specifications: ABNF", RFC 4234, October 2005. 267 6.2. Informative References 269 [2223BIS] Reynolds, J. and R. Braden, "Instructions to Request for 270 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis- 271 08.txt, August 2004. 273 Authors' Addresses 275 Christopher Inacio 276 Carnegie Mellon University 277 4500 5th Avenue 278 Pittsburgh, PA 15213 279 USA 281 EMail: inacio@sei.cmu.edu 283 Appendix A. 285 Relax-NG based definition of a proposed schema. Can be processed with trang to create a well defined XML XSD file. 287 namespace r = "http://www.ietf.org/ipfix/ipfix-private-element-registry/1.0" 289 # It's unclear what the right way of referencing an info element ought 290 # to be. By PEN/ID pair? By some XML ID? Both has problems. Leave it 291 # text for now. 292 info-elem-ref = text 294 r-data-type = element r:data-type { 295 "octetArray" | 296 "unsigned8" | 297 "unsigned16" | 298 "unsigned32" | 299 "unsigned64" | 300 "signed8" | 301 "signed16" | 302 "signed32" | 303 "signed64" | 304 "float32" | 305 "float64" | 306 "boolean" | 307 "macAddress" | 308 "string" | 309 "dateTimeSeconds" | 310 "dateTimeMilliseconds" | 311 "dateTimeMicroseconds" | 312 "dateTimeNanoseconds" | 313 "ipv4Address" | 314 "ipv6Address" | 315 "basicList" | 316 "subTemplateList" | 317 "subTemplateMultiList" 318 } 320 r-semantics = element r:semantics { 321 "default" | 322 "quantity" | 323 "totalCounter" | 324 "deltaCounter" | 325 "identifier" | 326 "flags" | 327 "list" 328 } 330 r-units = element r:units { 331 "none" | 332 "bits" | 333 "octets" | 334 "packets" | 335 "flows" | 336 "seconds" | 337 "milliseconds" | 338 "microseconds" | 339 "nanoseconds" | 340 "4-octet words" | 341 "messages" | 342 "hops" | 343 "entries" 344 } 346 #r-value-map = element r:value-map { 347 # attribute type {"integer" | "text" }, 348 # {element value } 349 #} 351 r-element = element r:element { 352 element r:id { xsd:integer {minInclusive="0" maxInclusive="65535"}} & 353 element r:private-enterprise-number { xsd:integer {minInclusive="0" maxInclusive="4294967295"}}? & 354 r-data-type & 355 r-semantics? & 356 r-units? & 357 element r:range-begin { text }? & 358 element r:range-end { text }? & 359 element r:name { xsd:token } & 360 element r:description { text } & 362 element r:mime-path { text }? 364 # element r:value-map { 365 # attribute type {"integer" | "text"}, 366 # } 367 } 369 r-registry = element r:registry { 370 element r:id { xsd:anyURI } & 371 element r:name { text } & 373 # Should these two be required or optional? 374 element r:security-type { text } & 375 element r:policy-type { text } & 377 element r:url { xsd:anyURI } & 378 element r:root-eid { xsd:integer } & 379 (r-registry | r-element)* 380 } 382 r-enterprise-registry = element r:enterprise-registry { 383 element r:name { text } & 384 element r:copyright { text } & 385 element r:contact { text } & 386 element r:private-enterprise-number { xsd:integer } & 387 element r:directory { xsd:anyURI } & 388 r-registry* 389 } 391 start = r-enterprise-registry 393 99.0. To be removed 395 The RFC Editor generally uses the simplest nroff features, basically 396 the "-ms" macro package and the following few basic nroff directives: 398 DIRECTIVE FUNCTION 400 .ce Center following line. 402 .ti # 'temporary indent' -- # is number of spaces. 403 Indents only the line immediately following. 405 .in # Change indentation to # spaces 407 .nf 'No fill': begin block of text to be displayed. 409 .fi Fill (i.e., left-justify, line wrap) 411 .ne # 'need' -- Keep following # lines on same page 413 .bp Break page 415 .br Break line 417 .KS 'Keep Start' -- lines up to .KE on same page 419 .KE 'Keep End' -- end of 'keep' block 421 Nroff also has a '.sp' (space) directive to insert a blank line. 422 However, it is far easier (and more readable) to use the fact that 423 each blank line in the nroff source creates a blank line in the 424 output. 426 Nroff includes many variations on the trivial commands shown above. 427 For example, indentation can be specified relative to the current 428 indentation, using '.in +#' or '.in -#'. Authors are welcome to use 429 such features, but for simplicity this template uses only the 430 simplest set of commands. 432 Some authors who are proficient in nroff will wish to use more 433 advanced features, including perhaps their own macros. This is a 434 private matter for the author, unless and until the document is 435 submitted to the RFC Editor for publication as an RFC. Upon document 436 submission, the RFC Editor will request the nroff source, if any. If 437 the source is sufficiently straightforward, it will be used by the 438 RFC Editor to speed the publication process. If not, the RFC Editor 439 will generate a new nroff source, generally using the simple subset 440 above. 442 The considerations here are as follows: 444 o Defined macros (beyond the -ms package) must be in-line at the 445 front of the source. The RFC Editor is currently prepared to 446 maintain only one source file for each published RFC. 448 o Some of the editors are not nroff experts, and even those who 449 may be do not have the time to figure out some complex/obscure 450 macro. If any special knowledge about these macros is needed 451 to modify the text for editorial purposes, the RFC Editor will 452 find it more expedient to generate a new .nroff source for the 453 document. 455 o The RFC Editor does not keep a distinct Make file for each RFC, 456 so it is not helpful to send us a tar file or shar script that 457 magically makes a directory and builds an RFC. Our primary 458 input is a .txt file, with a .nroff file as a possible 459 secondary input. When the RFC is published, the RFC Editor 460 will archive a .txt file and a corresponding \&.nroff file. 462 In other words, keep it simple and you can help us a lot; don't show 463 off your programming prowess and waste our time. 465 99.1. Formatting End of Page 467 The Unix command to create a formatted Internet Draft is: 469 "nroff -ms input-file.nroff > output-file.txt" 471 However, nroff will not follow the RFC standard format for a page: a 472 Form feed (FF or Control-L)) after the last visible line on the page 473 and no extra line feeds before the first visible line of the next 474 page. We want: 476 ^L 477 first visible line on page i+1 479 We invented hacks to fix this. The original hack was a "sed" script 480 that called a "C" program called "pg". More recently, we have been 481 using a simple Perl script (see Appendix A). Then the command to 482 process the nroff source file becomes: 484 nroff -ms input-file.nroff | fix.pl > output-file.txt 486 For example: 488 nroff -ms 2-nroff.template | fix.pl > 2-nroff.template.txt