From nobody Fri Jul 4 09:00:21 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74EA1A029D for ; Fri, 4 Jul 2014 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.352 X-Spam-Level: X-Spam-Status: No, score=-13.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Kx9GTVuMYEi for ; Fri, 4 Jul 2014 09:00:15 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E74F1B2841 for ; Fri, 4 Jul 2014 09:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34364; q=dns/txt; s=iport; t=1404489614; x=1405699214; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=6ze1zTZ724PBaC9AUFLegFS7leMtI5/+01VbB9pHjzU=; b=P+XUy9j9QnEnCnsSA2P3ORlrJie5pNCdbcnC7Q8wbp4HeCxdhV24lIy/ aSFV39ZEeANPSIwKI2TLgW3VSqyVlsVMcjQ3D7kaePZr/fy7f3L2Di9N4 NIgg7mXAVckooPmM0ywKczIUPZRV7lvzo59w6y6Oa4RNjKoJoU6r0pZHz 4=; X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="99825840" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 04 Jul 2014 16:00:12 +0000 Received: from [10.61.82.194] (ams3-vpn-dhcp4803.cisco.com [10.61.82.194]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s64G085f010963; Fri, 4 Jul 2014 16:00:11 GMT Message-ID: <53B6CF88.5080904@cisco.com> Date: Fri, 04 Jul 2014 17:00:08 +0100 From: Colin McDowall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipfix@ietf.org, Juergen Schoenwaelder , Benoit Claise References: <534C76C7.9030108@auckland.ac.nz> <20140418162115.GA3046@elstar.local> In-Reply-To: <20140418162115.GA3046@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/tjJBDTjvC78xVbly7x7Ru71ZYF0 Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:00:20 -0000 Hi Juergen, IPFIX List, This is a great and detailed review thanks. Paul and I have been working to address and resolve your comments. Paul should have a new version of the draft checked in later today. My comments are prefixed with "CM:" I've merged Paul's replies in as well at "PA:" I'll follow up with the replies to Benoit's reviews as well. Colin. On 18/04/2014 17:21, Juergen Schoenwaelder wrote: > On Tue, Apr 15, 2014 at 12:01:11PM +1200, Nevil Brownlee wrote: ... > I have reviewed the document and I believe it is not ready. The main > points: > > - Terminology needs to be aligned with SMIv2 > - I spotted several errors in the examples > - Major issues with the IE definitions in section 10 > - I also believe the introductionary text needs to improve. > CM: These 4 top level issues have been addressed as noted below. > /js > > I have reviewed draft-ietf-ipfix-mib-export-05 and I think it is not > ready and requires improvements. > > 1) The introduction contains details of the solution. I think it > should instead contain the motivation and the architectural model > currently in section 2. The new introduction should then be > followed by a terminology section before an overview of the > solution is provided (so that the terminology is defined). This is > primarily text reorganization. CM: Ok - the introduction section needs reworked. - Benoit had a good suggestion for this so I've implemented that. > > 2) I have trouble to understand the Figure "Architectural Overview". > I think this should be removed. Figure 4 is more useful and it is > at the right place in the document. CM: Yes, this is a simplified version of the same figure 4, added to help provide a high level overview of the approach. If it is more confusing than helpful it can be removed. Benoit had an issue with this figure not helping so I've removed it. > > 3) I have terminology issues in several places. For example, RFC 2578 > uses the term 'columnar object' for what this document seems to > call 'indexed object'. CM: I've updated all the references to indexed objects to columnar object. Fields that contain a columnar object are still referred to as indexed fields. This is because the export is including the index for that particular field. > Why is it useful to call Flow Records Data > Records? Using two terms for the same thing may just adds potential > for confusion. CM: As with Benoit's comment on this all the references to Flow Record have been updated to use 7011 except: This document prefers the more generic term "Data Record" (as opposed to "Flow Record") in relation to the export of MIB objects. We should only have Flow Record being used if we need a section discussing a difference between Flow and Non Flow Data Records. I don't think that needs discussion in this draft. > I also think more SMIv2 terms must be imported, such > as MIB module, MIB object, columnar object, ... CM: Agreed. I've imported more SMIv2 terms, the SYNTAX used in SMIv2 and the terms used to refer to SNMP contexts. > 4) There is a statement that providing index information for columnar > objects is optional. I have some difficulty to understand why this > is useful. CM: The exporting process may have a way to provide information to make unambiguous what the mib object value refers to via other key fields. In particular it has been useful to allow customers/implementors the freedom to use ipfix fields as best describes the problem being worked on. > What does "a MIB object is used purely as type > information" mean? CM: A MIB Object is providing a definition of a datatype that can be exported. This was one of the original goals of this draft, to allow the use of types already defined in the range of standard and non-standard MIBs without having to duplicate each object into an IANA ipfix information elements. When we are using the MIB modules purely to provide extra type information there should be no requirement on the implementer of the exporting process to also implement access to these via SNMP. See the following in the current introduction: > Rather than mapping existing MIB objects to IPFIX Information Elements on a case by case basis, >it would be advantageous to enable the export of any existing or future MIB objects as part > of an IPFIX Data Record. This way, the duplication of data models [RFC3444], both as SMIv2 MIB > objects and IPFIX Information Elements, out of the same information model [RFC3444] would be avoided. See 2nd last paragraph of Section 2 (-05 draft): > Another advantage of exporting MIB objects via IPFIX is that IPFIX > would benefit from an extended series of types to be exported. The > simple and application-wide data types specified in SMIv2 > , along with a new Textual Conventions, can be > exported within IPFIX and then decoded in the Collector. > ... CM: Also of note is that as documented in rfc 3410 the management information and the data definiton languages are independent of the protocol used to export the data. This is just the first step in providing an alternative/replacement to SNMP to export MIB Object data. If exporting data about a columnar object without fully indexing it would always be incorrect we can add a requirement that indexing MUST be used and remove the bits making it optional. > How can an exporting process not have access to > index information of a columnar object? CM: If there is not a SNMP or MIB process running on the exporting device. In particular the exporting device may not implement the MIB Objects that are being used as INDEX fields. Alternatively an exporting device may be aggregating data from several simpler exporters that don't understand fully how the data they are sending to the aggregating process needs to be indexed. > > 5) The terminology sections says a "MIB Object Identifier" is an ASCII > character string of a certain format but it seems later a BER > encoded representation is used for mibObjectIdentifier. This seems > inconsistent. > CM: I think this definition was originally taken from the SMIv2 document. I've replaced this with the relevant text from rfc2578. Maybe this should be replaced with just a reference to SMIv2 as per your comment 3 though. > 6) "exporting a value from a MIB does not imply that the SNMP process > on the device supports that MIB" > > Proper wording would be something like this: > > "exporting a value of a MIB object defined in a certain MIB module > does not imply that the SNMP prcess on the device supports that > MIB module" CM: Fixed. > > Similarly, "exporting MIBs in IPFIX" should be "exporting values of > MIB objects". > CM: Fixed. > The paragraph on page 9 is also the first occurance of the term > "MIB Field" - without a clear definition what this means. > CM: I could either change this to use the same terms as the rest of the document or provide a definition for this term. Since this is a hypothetical, negative case that we aren't standardizing I think I'll just make this paragraph more general. Changed to: > The values of a MIB Object could be exported using a MIB specific Information Element without providing any Object Identifiers. > However, without exporting the actual MIB OID the full type of the data would be unknown and every Field containing MIB Object data would appear identical. > Without knowing which OID the contents of a Field map to the data would be incomprehensible to a Collector. > 7) This text needs rewrite: > > Since these values are statically defined in the MIB they are not > expected to change frequently. However the additional information > about the MIB may help a Collecting Process that does not have access > to the MIB. > > NEW > > Type information is statically defined in a MIB module, it is not > expected to change. However, the additional information about the > MIB Object may help a Collecting Process that does not have access > to the MIB module. > CM: Replaced with your NEW version. > 8) Is it mibTypeOption of mibSubTypeOption? Both words are used, or > are these different things? > CM: Yep that should be mibTypeOption only, I've fixed the typo. > 9) I fail to parse/understand these statements: > > Forf each of these the options this draft specifies exactly which > mibObjectValue to use. > CM: Removed the extra these and clarified. Now reads: > For each of the SYNTAX clause options this draft specifies exactly which mibObjectValue to use. > [...] > > If the SYNTAX clause contains a Textual Convention or Subtyping the > mibObjectSyntax Information Element SHOULD be used to export this > detail to the Collecting Process. CM: I'm not sure what is wrong with this. To paraphrase this a little, if the type information is complicated the export process SHOULD export the full details of the type to the collector. For example include the mibObjectSyntax field in a mibTypeOption export. The idea is that in the more complicated cases or with textual conventions the base type of the MIB Object does not fully convey the type of the data. The collector either needs to have access to the MIB module definition or be sent the SYNTAX text. > > 10) It escapes me how mibObjectValueSequence and mibObjectValueTable > are used / encoded. And why does the first one use an ASN.1 type > name while the second uses an SMIv2 conceptual term? This seems > inconsistent, either call them mibObjectValueSequence and > mibObjectValueSequenceOf or mibObjectValueRow and > mibObjectValueTable. > CM: These are exported using IPFIX Structured data. The key point is that while SNMP has all access as scalar single values with IPFIX we can define compound data structures. So rather than having a conceptual row - we can export an actual row with all the values for that row together. Likewise with a table. We can export a list of rows to send a complete conceptual table in one field. This means that an exporting process / export designer can correlate a row of stats from a MIB with other IPFIX fields easily. See section 4.8.2 for how a conceptual row is exported See section 4.8.4 for how a complete table can be exported. I like the names mibObjectValueRow and mibObjectValueTable though and since that moves to using just SMIv2 terms I've renamed those. > 11) This text is unclear and needs a rewrite. I think I understand > what you are trying to communicate but the wording needs > improvements. (And it is a MIB module here, not a MIB.) > > This holds true even if the data carried inside the mibObjectValue or > mibObjectIdentifier may be related to an enterprise specific MIB. > The OID itself encodes if the Object is in an Enterprise specific MIB > Module. > CM: Yes, this wording originated from the example you suggested cutting from a previous draft. I've reworded it as follows: The MIB Object being exported may be defined in an enterprise specific MIB module but the Information Elements defined in this standard are still exported with the E bit set to "0". The OID exported encodes that the MIB object was defined in a Enterprise specific MIB Module. > 12) What does "Field Length (mib)" stand for? Is there anything > special or is this just a plain normal "Field Length"? If so, I > would rather remove the "(mib)" annotation. CM: This is so that the note below the figure can refer to this particular part of the diagram. I could number the length fields if that is clearer or less confusing. > > 13) I suggest to replace "more information about MIB indexing, extra > data from the MIB" with "additional information about the MIB > Object definition" CM: Updated. > > 14) Rewrite "... a reference to a MIB that ..." - I think you mean a > MIB Object. > CM: Fixed. > Rewrite "may not have access to the MIB" -> "may not have access to > the MIB module". CM: Fixed. > > And then I am getting lost here: > > [..] It also allows the IPFIX Field Types to be extended with > any MIB Variable already defined purely through IPFIX. > > It is not clear what is communicated here. CM: Ok, I've reworded that. > > 15) Section 4.4.6 has more inaccurate usages of the term "MIB" but > more important, CM: Fixed those. > I wonder what actually the OID is that is being > shipped in mibObjectIdentifier. Is it the OID assigned to the > object type definition or is it the OID of the instance of an > object type? Have I overlooked where this is clearly defined? CM: This is already defined in the definition for the mibObjectIdentifier IE: Section 10.2.1: > The mibObjectIdentifier Information Element contains the OID assigned to > the MIB object definition encoded as ASN.1/BER I can add the word type in there to make it clearer though: Section 10.2.1 changed to: > The mibObjectIdentifier Information Element contains the OID assigned to > the MIB Object Type Definition encoded as ASN.1/BER > > 16) Terminology: "MIB Sequence Object's INDEX clause" -> "INDEX > clause of a conceptual row object". CM: Changed to: > However, fields used as an INDEX MUST be in the same order as specified in the INDEX clause > of the conceptual row MIB Object. > > 17) s/then the MIB context MUST/then the context MUST/ > > MIB context is not a defined term. There are only SNMP contexts. > (Perhaps they should have been MIB contexts but this is a > different story.) > CM: Fixed. > 18) s/the exported to export/the exporter to export/ CM: Fixed. > > 19) Section 4.8 is rather confusing, primarily because the terminology > is not aligned with SMIv2 terminology. This affects almost all > sentences. In SMIv2, terms like "MIB SEQUENCE Objects" do not > exist. SMIv2 calls this a 'conceptual row object'. This section > needs to be rewritten to align with SMIv2 terminology (this means > getting rid of almost all occurrences of 'sequence' (in any > capitalization)). Terms such as "full OID" are ambiguous unless > you say what the OID is supposed to refer to. Ok, I've updated this section to refer to conceptual rows and tables. I think I was understanding an OID refereing to an instance of a MIB Object as a "full OID". I think this was in the initial version of this document - it is probably where I learned this term. > > The first item in 4.8 talks about ingoring the indexing of > columnar objects and later says "a columnar object may be used > purely as a data type. I have a difficulty to understand how that > would be useful. Again the a columnar MIB object can only ever have 1 set of index fields for the row it is in. We want to be able to use the new MIB fields in combinations with any other IPFIX field when useful / understandable. Also for the simplest cases and simplest exporters we want to make it easy to send data matching the MIB object type without having to introduce arbitary indexes when not required. We need to provide a mechanism to export indexing information, but we shouldn't require it. I also can't see the use case of looking up a mib to check the value you have just received, Ideally we want to replace snmp to provide access to the model, not just send a duplicate traffic stream. > > On page 33, a paragraph refers to section 7.7. of RFC 2578 and I > am confused what it tries to say here. So far, I assumed that the > OIDs all refer to columnar objects or conceptual row objects and > include no instance identifiers. All the OIDs exported in the mibObjectIdentifier are OIDs for the object defitions. I've clarified the text: The mibIndexIndicator marks the Fields whose value(s) should be added to the OID for the MIB Object type definition exported in mibObjectIdentifier to get the OID for the instance of the MIB Object. I've also deleted the references to fully indexing an Object. > > I do not understand the last paragraph before section 5. OK, the idea was to prevent the daisy chain effect of exporting a lot of mib objects just to satisify indexing requirements. It is probably just better to use the provision to not provide the index details rather than use an opaque number. Taking account of your comment on the example that uses this it has been removed here as well. This paragraph is now gone. > > 20) The first enumerated item in Section 5.1 says "flowStartSeconds > from [RFC7012]" but then RFC 7012 does not define this anymore > (but its predecessor RFC 5102 did). Since Section 5.2 has the same > text, the same issue needs to be resolved there. CM: Update to refer to IANA-IPFIX as the definition of these fields. > > 21) Sections 5.1. and 5.2 both contain references to themselfs "(see > Section 5.x)" which does not seem to make much sense. Last sentence > on page 38: s/this identical/this is identical/ CM: Fixed - the references weren't adding anything. Sentence fixed > > 22) I looked up the definition of cpmCPUTotal1minRev and it turns out > that this is a columnar object (which makes sense since you can > have multiple CPUs). Since you do not export information about > which CPU the load value is coming from, how useful is the > information and does this make a good example? > CM:This is a good example of using the columnar object without providing the full indexing of which CPU the information relates to. Without providing any more fields the implicit scope would be interpreted as being the CPU total for the exporting device. If there is only 1 CPU how has adding extra indexing or a whole extra column helped with the export or clarity of the data. However the text refers to the CPU usage as being a non columnar object, that needs to be fixed. Updated text: Although the cpmCPUTotal1minRev MIB Object is a columnar object in a conceptual row, while there is only 1 CPU no extra information is conveyed by providing the INDEX field. So in this case it is acceptable to not export the cpmCPUTotalIndex MIB Object. If there were multiple CPUs it would be appropriate to include this the cpmCPUTotalIndex field and specify the relationship. > 23) Section 5.3. needs a title change. It is about exporting a subset > of a conceptual row. Perhaps something like this: > > 5.3. Exporting a Conceptual Row: The OSPF Neighbor Sequence > CM: Fixed using your text > The last sentence on page 40 refers to Table 7 but I assume you > mean Table 5. > CM:Fixed. > 24) The BER encoding of 1.3.6.1.2.1.14.10.1 is 06082B060102010E0A01 > (10 octets) and not the 22 octets shown in Figure 28. > CM: This appears to have been an artifact of the code I was using to generate the BER encoding - my binary/hex encoding appears to have been padding extra 0's that weren't required. I did check each OID in the previous version that through a web based ASN decoder since I didn't trust myself to get it right - http://lapo.it/asn1js/. The decoded output for your version and the old one was identical. I've fixed that. Curious. 060f2b8006800180028001800e800a8001 06082B060102010E0A01 Anyway I'll update the OIDs throughout the document to use your ones and fix the sizes of the examples as required and double check them. > 25) Section 5.4. also needs a better title, e.g. > > 5.4. Exporting an Augmented Conceptual Row: ifTable and ifXTable CM: Fixed. > > The text in section 5.4 confuses ifXEntry and IfXEntry. A possible > rewrite: > > The ifTable defined in the IF-MIB [RFC2863] is augmented by the > ifXTable (defined in the same MIB module). The OID of the > ifEntry is 1.3.6.1.2.1.2.2.1 while the OID of the augmenting > ifXEntry is 1.3.6.1.2.1.31.1.1.1. This example demonstrates how > columnar objects from the base conceptual row and the augmenting > row can be exported in a single mibObjectValueSequence data > record. CM: Replaced using your text but updating the mibObjectValueSequence to mibObjectValueRow and data record -> field > > 26) Why is the Field Length of mibObjectValueOctetString (on page 46) > 16 octets? The ifName's restriction is 255 octets. And should this > not be variable length? CM: The longest name we are trying to export in this example is 16 bytes long. This field is being reduce length encoded, it is one reasonable choice for the export process developer to get the longest string the they are going to be using and have that as the length. The better solution is, as you say,to use variable length, but I don't think it adds much to this example. > > 27) page 47: s/VLAN=11/VLAN=10/ CM: Fixed > > On page 48, I am surprised that ifType and ifMTU are both 16-bit > fields. Does the template not say they are 4 octets long? CM: Yep that is a mistake. Fixed in the template to specify both fields are 2 bytes long. > > 28) Section 5.5. also needs a new title and the terminology used is > wrong as well. Perhaps it is: > > 5.5. Exporting a Columnar Object: ipIfStatsInForwDatagrams > > Please do not write 'ipIfStatsTable SEQUENCE'. The correct SMIv2 > term is conceptual table. (And also note that the ASN.1 type of a > table is a SEQUENCE OF and not a SEQUENCE.) > I've removed all refererences to SEQUENCE except when refering to the SYNTAX clause in "Section 4.3 - IPFIX and MIB Data Model" > The template in Figure 33 says the interface index is two octets. > This may be true for a certain exporter but may not be generally > true - it may be worth to be explicit about the assumption made > here that all possible interfaces are numbered such that they fit > into 16 bits. CM: Added a note to that regard. > > The BER encodings and the corresponding VLEN fields are all wrong > in Figure 35: > > 1.3.6.1.2.1.4.31.3.1.1 -> 060A2B06010201041F030101 (12 octets) > > 1.3.6.1.2.1.4.31.3.1.2 -> 060A2B06010201041F030102 (12 octets) > > 1.3.6.1.2.1.4.31.3.1.12 -> 060A2B06010201041F03010c (12 octets) > CM: Fixed OIDs and lengths of Variable fields and whole set. > 29) Section 5.6. needs a better title. This is about a columnar object > where the index information is provided by IPFIX information > elements. > > 5.6. Exporting a Columnar Object index by IEs: ifOutQLen CM: Fixed > > s/be done be/be done by/ CM: Fixed > > The text below Table 8 needs to be rewritten, e.g. > > The ifOutQLen MIB object defined in the IF-MIB [RFC2863] provides > the length of the output packet queue. This columnar object is > part of the ifEntry conceptual row and indexed by the interface > index (ifIndex). CM: Agreed and updated to use the above text. > > I am not sure I agree on the second paragraph on page 53. I tend > to believe that the index information must be provided for generic > applications to make sense out of the data. CM: While I think there are many MIB Objects that will only make sense if the full indexing is provided, there will be many others where the index information is optional or an alternative can be provided. Regardless this paragraph doesn't add anything useful, explain it well or belong in this section so I've removed it. > > The BER encoding and the corresponding VLEN in Figure 39 is wrong: > > 1.3.6.1.2.1.2.2.1.21 -> 06092B0601020102020115 (11 octets) > CM: Fixed > 30) I find the example in section 5.7 rather strange. Why would one > export the ifIndex value using mibSubIdentifier and not by > including the ifIndex proper? There does not seem to be any > savings and this mibSubIdentifier approach of course is only > applicable where the number of sub-identifier is constant for all > conceptual rows. Since I do not see that this approach is needed > nor that it adds any value in terms of more compact encodings, > I would actually prefer this to be removed and perhaps even be > disallowed. > > The BER encoding of the ifOutQLen OID is wrong, see above for the > correct value. > > (The caption of Figure 44 is kind of strange because it says > "using ifIndex" but then the example is about not using ifIndex > but instead an opaque number.) > > This section 5.7. should really be removed I think. > CM: On reflection I agree, making indexing optional is enough flexibility. This was originally added to prevent a cascade of having to support all the fields in the INDEX, but it really just adds an extra option that is not needed and confusion. The main problem I see is your point about not being sure of the number of subidentifiers, we would have to make it a list and even more complexity for no gain. mibSubIdentifier is now only defined to be used in a Mib Field Option so I've moved it's definition with the other mibFieldOption fields. > 31) In section 5.8, > > s/ospfNbarEntry/ospfNbrEntry/ CM: fixed throughout > > The OID encoding and the VLEN field in Figure 46 is wrong: > > 1.3.6.1.2.1.14.10.1 -> 06082B060102010E0A01 (10 octets) > CM: Fixed. > RFC 3411 uses '800002b804616263'H as an snmpEngineID in examples. > CM: Ok updated to use the same example. And fixed the lengths to match. > 32) What is the meaning of this: > > If a Collecting Process receives a MIB Object Identifier that it > cannot decode, it SHOULD log an error. > > What does 'cannot decode' mean? I mean, a simple collector may > just store the records in some file / database. So what is > expected here? And why is it an error and not a warning? CM: This requirement carried over from the first version, where the data being sent was just some bytes and without access to the MIB module the collector could not understand the format at all. Now a collector that supports all the fields will know the basic type of the data it is much more reasonable to store the data for later decoding. I've added instead a paragraph here that mentions that the OIDs be stored with the same policy as templates. I've downgraded the unknown thing to a warning. In some cases the collector would be expecting to understand each MIB and if it gets an unexpected or corrupt value reporting a warning is reasonable behaviour. > > I am also not sure what the last paragraph in section 7 tells me. > What does 'purely semantic information' mean? For me, if you miss > the semantics, the data has no value. But I understand that IPFIX > people have a very different terminology at times. > CM: It is sort of making the point that the export may not be from a full MIB implementation on the exporting process - and that the Object Definition is just being used in place of a pure IPFIX IE number. > 33) It is unclear to me how the export of conceptual rows deals with > non-existing variables (aka table holes). Is there a mechanism in > IPFIX to indicate that a certain field of a flow record does not > have a value? CM: This is the subject of draft-aitken-ipfix-unobserved-fields-02. There needs to be a general solution to this problem, which would apply well here, but this is not the draft to try to solve the problem. > > Issues with section 10: > > a) In the SMIv2, we distinguish between Counter32 and Counter64 and > I think this difference important to capture since the rollover > is different. The I-D seems to map both to mibObjectValueCounter. > PA: mibObjectValueCounter simply contains the value of the counter, which is independent of the type. The mibType Information Elements should be used to distinguish between Counter32 and Counter64. > b) The descriptions all use the phrase "from a MIB" but I think it > should be "of a MIB object". > PA: Done. > c) The SMIv2 type is IpAddress and not IPAddress. PA: Done. > > d) The definition of mibObjectValueCounter says "Data Type Semantics: > totalCounter". I think this is wrong since SMIv2 counters do not > start with zero. Furthermore, a Counter32 rolls over after 32-bit > and not after 64-bit (but mibObjectValueCounter is an unsigned64). PA: The point of the "totalCounter" semantic is to indicate that the value is absolute rather than a delta. I've added a new IPFIX "SNMPtotalCounter" semantic for this. Despite the 64-bit mibObjectValueCounter definition, Counter32 can be exported in a 32 bit mibObjectValueCounter using "Reduced Size Encoding" per http://tools.ietf.org/html/rfc7011#section-6.2 The correct semantic (counter32, counter64) can easily be determined from the field length. > > e) The definition of mibObjectValueGauge "Data Type Semantics: > totalCounter". I think this is wrong, a Gauge32 is not a counter. > And it might be useful to call this mibObjectValueGauge32. PA: Changed the semantics to "gauge" and added a new IPFIX "SNMPgauge" semantic for this. Naming it "mibObjectValueGauge32" unnecessarily conflates the type and the size, so a new type would be needed for each different gauge size (eg gauge64). The correct semantic (gauge32, gauge64) can easily be determined from the field length. > > f) Why did you call mibObjectValueTime not mibObjectValueTimeTicks? > The "Abstract Data Type: dateTimeMilliseconds" also seems to be > wrong since TimeTicks are _not_ measured in milliseconds since > 1970-01-01T00:00. You may want to use unsigned32 and spell out the > semantics. PA: Renamed to "mibObjectValueTimeTicks" and changed to u32. > > g) mibObjectValueUnsigned used the "Abstract Data Type: unsigned64" > which is wrong since there is only a 32-bit unsigned type in the > SMIv2. I suggest to use unsigned32 and to rename this to > mibObjectValueUnsigned32. PA: Unsigned64 is used to allow future exports of 64 bit values. IPFIX's "Reduced Size Encoding" allows 32 bit values to be exported despite the u64 semantic. > > h) The phrase "a complete MIB 'SEQUENCE OF X' or conceptual table > value" reads strange. Similarly, "a MIB SEQUENCE or a row from a > conceptual table" reads strange. Perhaps simply use "a complete > conceptual table" and "a row of a conceptual table". PA: Done. > > i) The lest sentence of the Description in 10.1.11 seems to be missing > some words. PA: Good catch: "The template specified in the subTemplateList MUST be an Option Template..." > > j) The description of 10.2.2 is somewhat confusing: "... that serves > as INDEX MIB Objects of Information Elements for a mibField". In > SMIv2, the INDEX is associated with a conceptual row. PA: Changed to, "that serve as INDEX MIB objects for an indexed Columnar MIB object." for consistency with the remainder of the paragraph. > > k) What does "sampled by SNMP" mean? Do you hook into the > instrumentation or do you access things via the SNMP agent? PA: That's an implementation issue. Our concern is only to indicate how fresh the data value is. > > l) p74: s/the MIB the Flow/the MIB when the Flow/ PA: Good catch. > > (Note that you are talking about a flow here and not about a data > record. I think this is goodness and proves that a new term is not > needed.) PA: A Flow is a sequence of packets which we're observing. It's an input. A Flow Record contains information about an observed Flow. It's an internal object. A Data Record contains values indicating observations which were made. It's an output. A Flow could have started a long time before the metering process began, so I clarified the text to: begin - The value for the MIB object is captured from the MIB when the Flow is first observed end - The value for the MIB object is captured from the MIB when the Flow ends export - The value for the MIB object is captured from the MIB at export time average - The value for the MIB object is an average of multiple captures from the MIB over the life of the Flow CM: I updated the average case to mention the observed life of the flow > > m) Replace the Description in 10.3.4 with this: > > Description: The textual name of the MIB module that defines a MIB > Object. PA: Done. > > n) I do not understand what mibObjectSyntax would contain for an object > representing a conceptual table or a conceptual row. For say ifEntry, > would it be just "SEQUENCE { > ifIndex InterfaceIndex, > ifDescr DisplayString, > -- lots of stuff left out > }"? And what would it be for the object representing the conceptual > table? Or do you just mean what is literally in the SYNTAX clause, > excluding the referenced ASN.1 type definitions? PA: Literally just the SYNTAX clause. CM: Yes I meant that the Syntax is literally the output in the SYNTAX clause. > o) Remove "( also known as snmpEngineID) that" since it is potentially > misleading. > > Explanation: Every SNMP engine has a unique snmpEngineID. The > combination of a snmpEngineID value and a context names provides > the SNMP context. Note that an SNMP engine may provide access to a > non-local context, in which case the values of snmpEngineID and > contextEngineID would be different. > > PA: Done. From nobody Fri Jul 4 09:08:38 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD891B29F4 for ; Fri, 4 Jul 2014 09:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8PAp-oAJ5T3 for ; Fri, 4 Jul 2014 09:08:34 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2881B2827 for ; Fri, 4 Jul 2014 09:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4914; q=dns/txt; s=iport; t=1404490114; x=1405699714; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=VzHZLoIUgHksBASezmyegVg7gzrfghPOFl7iXPGeKnE=; b=Mxcb9ypLTqCeJex/eWmD8LAzVvR5ddjqw1Vl6Fb/ridhNI3+w8Aa6ElT tAXOIctQGoaTkI7IvDZoHNCTFp7VuBLbmNh3+B0gkOwquC8CH/JHK//9R FjHpdTiZYLUSAbPxKOE8G9O/6tnqGilSNCPJNrZCUzA0eHHnnPyYbHNRX U=; X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="104565594" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Jul 2014 16:08:32 +0000 Received: from [10.61.82.194] (ams3-vpn-dhcp4803.cisco.com [10.61.82.194]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s64G8VaQ021257; Fri, 4 Jul 2014 16:08:31 GMT Message-ID: <53B6D17F.2010308@cisco.com> Date: Fri, 04 Jul 2014 17:08:31 +0100 From: Colin McDowall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipfix@ietf.org, Benoit Claise References: <534C76C7.9030108@auckland.ac.nz> <20140418162115.GA3046@elstar.local> <535A6474.5030706@cisco.com> In-Reply-To: <535A6474.5030706@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/2TxdSsEiPZozocHNvKBKO3ygDvk Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:08:36 -0000 Hi Benoit, all, See CM: for more replies for the last review of draft-ietf-ipfix-mib-variable-export-05. On 25/04/2014 14:34, Benoit Claise wrote: > Dear all, > > Some feedback on the sections I already reviewed. > Note that I agree with Juergen's feedback. ... >> 1) The introduction contains details of the solution. I think it >> should instead contain the motivation and the architectural model >> currently in section 2. The new introduction should then be >> followed by a terminology section before an overview of the >> solution is provided (so that the terminology is defined). This is >> primarily text reorganization. > The following text could be cut/pasted from the Introduction to a new section "High Level Solution Overview", somewhere after the terminology section: > > This document specifies a method for creating IPFIX Option Templates > that are used to export the extra data required to describe MIB > variables (seeSection 4.1 ). > > This allows IPFIX Templates to contain any combination of fields > defined by traditional IPFIX Information Element(s) and/or MIB Object > Identifier(s). The MIB Object Identifiers can reference either non- > indexed or indexed MIB object(s). Enterprise-specific MIB Object > Identifiers are also supported. > > This document also defines three standard Option Templates (see > Section 4.2 ) that are used as part of the mechanism to export MIB > Object meta data: > > o mibFieldOption (Section 4.2.1 ) > > o mibSubFieldOption (Section 4.2.2 ) > > o mibTypeOption (Section 4.2.3 ) > > This document defines three classes of new IPFIX Information > Elements. These are used to export values from the MIB, export > required Object Identifier information, and optionally export type > data from a MIB Module: > > o mibObjectValue Information Elements (Section 10.1 ) > > o mibFieldOption Information Elements (Section 10.2 ) > > o mibTypeInformation Information Elements (Section 10.3 ) > CM: Agreed and implemented - the introduction is now a lot leaner and better. > >> >> 2) I have trouble to understand the Figure "Architectural Overview". >> I think this should be removed. Figure 4 is more useful and it is >> at the right place in the document. > Agreed. CM: Ok that figure has been removed. >> >> 3) I have terminology issues in several places. For example, RFC 2578 >> uses the term 'columnar object' for what this document seems to >> call 'indexed object'. Why is it useful to call Flow Records Data >> Records? Using two terms for the same thing may just adds potential >> for confusion. > From RFC 7011: > > +------------------+---------------------------------------------+ > | | Contents | > | +--------------------+------------------------+ > | Set | Template | Record | > +------------------+--------------------+------------------------+ > | Data Set | / | Data Record(s) | > +------------------+--------------------+------------------------+ > | Template Set | Template Record(s) | / | > +------------------+--------------------+------------------------+ > | Options Template | Options Template | / | > | Set | Record(s) | | > +------------------+--------------------+------------------------+ > > Figure A: Terminology Summary Table > > Section 3 provides: > > This document prefers the more generic term "Data Record" (as opposed > to "Flow Record") in relation to the export of MIB objects. > > So flow record should be changed to data records throughout the doc. CM: Done except for one mention in the above text you mentioned This document prefers the more generic term "Data Record" (as opposed to "Flow Record") in relation to the export of MIB objects. Thanks, colin From nobody Fri Jul 4 09:23:32 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40CD1B2D8A for ; Fri, 4 Jul 2014 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.152 X-Spam-Level: X-Spam-Status: No, score=-14.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aRhCkvzznlu for ; Fri, 4 Jul 2014 09:23:27 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18891B2C37 for ; Fri, 4 Jul 2014 09:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22418; q=dns/txt; s=iport; t=1404491006; x=1405700606; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=0XeNxVEzSPoi9rf0/J+zzm2bdYR2RrWcTTZ/dWpsH6s=; b=brJbtACJ0bdS7gwW4F5jnP7fadJWkkvQejj5U1yYzWOteLKe2mAUYNa8 KQSSTzDcROih7Npfa6yabr/o+IbZWeXlMHkMyLN+n6YwsjS8IinGWcWqW dTTn9bPbAMyVuybvxMjbJiTh70gTCHCqbV928JE6OVmTqDcSzRjS3M+OL o=; X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="99814536" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 04 Jul 2014 16:23:25 +0000 Received: from [10.61.82.194] (ams3-vpn-dhcp4803.cisco.com [10.61.82.194]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s64GNOha002470; Fri, 4 Jul 2014 16:23:25 GMT Message-ID: <53B6D4FC.2030309@cisco.com> Date: Fri, 04 Jul 2014 17:23:24 +0100 From: Colin McDowall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipfix@ietf.org, Benoit Claise References: <534C76C7.9030108@auckland.ac.nz> <535A63DC.3090308@cisco.com> In-Reply-To: <535A63DC.3090308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/rTrSmm7jyGn7iZVgPaKOJvEVkUo Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:23:32 -0000 Hi Benoit, all, This is great feedback, thanks. Please see replies at CM: Paul should have draft -06 submitted today. On 25/04/2014 14:32, Benoit Claise wrote: > Dear all, > > I stopped my review at section 4.4.2 (spent a couple of hours already), and I'm afraid the draft is not ready. > Here is my feedback. > > - Section 1 > > For example, > in the IPFIX information model [RFC7012 ], Information Elements coming > from the SNMP world have already been specified, e.g., > ingressInterface and egressInterface both refer to the ifIndex > defined in [RFC2863 ]. > > As Jürgen noted, RFC 7012 doesn't specify the IPFIX information elements any longer. > This is done in the IANA registry. CM: updated to refer to IANA. The only remaining reference t rfc7012 is in Paul's new semantics section that is refering to a section of that draft rather than IEs. > > - Section 2 > > In the best case, assuming very tight integration of > an IPFIX Collector with and SNMP polling engine, SNMP data is > retrieved shortly after Data Records have been received, which > implies a delay of the sum of the active or inactive timeouts (if > not null) plus the time to export the Flow Record to the > Collector. > > For active and inactive timeouts, provide a reference to RFC 5470 , section 5.1.1. "Flow Expiration" > Even if RFC 5470 doesn't call them active and inactive timeouts (btw, don't change that, these are well known terms), this is a good reference. CM: Added the reference. > > - Section 2 > > This draft does not specify SNMP notifications, even if the > specifications in this document could potentially allow this. > > draft -> document > Same remark for: > > For each of these the options this draft specifies exactly which > mibObjectValue to use. > > This draft defines two forms of indexing that can be used for > SEQUENCE MIB Objects. CM: All uses of draft in the main body changed, now only mentioned in the Acknowledgements. > > - Section 2 > > The > simple and application-wide data types specified in SMIv2 [RFC2578 ], > along with a new Textual Conventions > > Remove the s CM: Went the other way and removed the 'a' to make the sentence read: The simple and application-wide data types specified in SMIv2 , along with new Textual Conventions, can be exported within IPFIX and then decoded in the Collector. > > - Section 3 > > mibObjectValue > > Refers to any and all of the mibObjectValue Information Elements > generically. Any restriction or requirement in this document that > refers to mibObjectValue applies to the following Information > Elements defined inSection 10.1 : mibObjectValueInteger, > mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS, > mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime, > mibObjectValueUnsigned, mibObjectValueTable and > mibObjectValueSequence. > > Change mibObjectValue to mibObjectValue Information Elements. > This is how it's used in some sentences in the rest of the document. > However, I also see: mibObjectValue Field or mibObjectValue field > I don't know what the term field refers to. Please change this to mibObjectValue Information Elements CM: wow didn't realise field wasn't an ipfix term. I've updated all the references to mibObjectValue fields to refer to mibObjectValue Information Elements > > - Section 4 > > The Exporting process MAY extract the data values for mibObjectValue > fields from a Process that resides on the same device or MAY capture/ > create the data required to match the definition of the MIB Object. > In particular exporting a value from a MIB does not imply that the > SNMP process on the Device supports that MIB. > > Why is Process capitalized? CM: I think it was originally Exporting Process - but the process capturing values from an on board mib may not be the actual Exporting Process > Also MAY to may. This is not a RFC 2119 keyword required for the implementation. CM: ok moved to lower case. > > - Section 4 > The main issue that arises from exporting MIBs in IPFIX is that MIB > Object Identifiers do not fit into the standard IPFIX Template format > [RFC7011 ], as this only provides a 16-bit Information Element > identifier and the length of the Information Element. > > I would remove "and the length of the Information Element", which doesn't add anything to this sentence CM: Agreed, fixed. > > - Section 4 > > One approach to this problem would be to extend the IPFIX standard to > allow extended field specifiers so metadata about Fields can be > included in Data Templates. > > Fields -> field CM: lowercased but kept it in the plural: so metadata about fields can be included in Data Templates. > > - Section 4 > > However, future versions of IPFIX MAY export the required MIB > metadata as part of newer set versions. > > MAY -> may. > Please review all RFC 2119 keywords CM: This was an attempt to not limit future implementations of IPFIX from having to implement the export of the OID data in the same format. I've moved that to lower case though, since we can only define behaviour for the current version in this draft. I've considered all the 2119 keywords and I think those left are now required. > > - Section 4 > This is a > standard IPFIX Option Template Set that MUST include a minimum set of > required fields (seeSection 4.2.1 ) and MAY include extra fields to > provide more meta information about one of the mibObjectValue fields. > > While you're not yet in the specifications in Section 4, I would not introduce MUST and MAY here. > This also contradicts the REQUIRED and RECOMMENDED in section 4.2.1 > Please group the RFC 2119 keywords in section 4.2.1 CM: Ok, the RFC 2119 keywords relating to the option export have been grouped into that section. > > - Throughout the document > Option Template -> Options Template > Note: IIRC, there were inconsistencies in RFC 5101, which were corrected in RFC 7011 CM: Fixed throughout > > - Major issue: I confused by mibFieldOption > Is this a IE or an Options Template? > > The TOC shows: > 4.2. MIB Field Options - Specifications and Required Fields . 11 > 4.2.1 . mibFieldOption . . . . . . . . . . . . . . . . . . .12 > 4.2.2 . mibSubFieldOption . . . . . . . . . . . . . . . . . .13 > 4.2.3 . mibTypeOption . . . . . . . . . . . . . . . . . . . .13 > 4.3 . IPFIX and MIB Data Model . . . . . . . . . . . . . . . .14 > 4.4 . MIB Field Option Template Formats . . . . . . . . . . . .15 > 4.4.1 . Data Template containing a mibObject Field . . . . .15 > 4.4.2 . mibFieldOption Template . . . . . . . . . . . . . . .17 > 4.4.3 . mibFieldOption Data Records . . . . . . . . . . . . .18 > 4.4.4 . Option Template containing a mibObject Field . . . .19 > 4.4.5 . mibFieldOption Template with Semantics Fields . . . .20 > 4.4.6. mibFieldOption Template with extra MIB Object Details 21 > > It's not clear! > > This document also defines three standard Option Templates (see > Section 4.2 ) that are used as part of the mechanism to export MIB > Object meta data: > > o mibFieldOption (Section 4.2.1 ) > > o mibSubFieldOption (Section 4.2.2 ) > > o mibTypeOption (Section 4.2.3 ) > > Ok, so these are Options Templates. > If this is the case, change the TOC section titles > > Then I see in figure 1 > +------------------------+ > | mibFieldOptionTemplate | > +------------------------+ > What is a mibFieldOptionTemplate ? > > This document defines a mibFieldOption Template to export the extra > meta information required for a mibObjectValue field. > > Well, this one above is wrong. This should be Options Template, right? > > Then I see > 2. A mibFieldOption Template Set > > The mibFieldOption Template describes which metadata will be > sent for each mibObjectValue being exported. > > These should be Options Template Set, right? > > Then, I look at > > > 4.2.1. mibFieldOption > > > Three fields are REQUIRED to unambiguously export a standalone > mibObjectValue Field with a mibFieldOption: > > > Then I look at > > > 4.4.2. mibFieldOption Template > > The mibFieldOption Template is a Standard Option Template which > defines the Fields that will be exported to provide enough metadata > about a mibObjectValue so that the Collector can tie the data values > in the mibObjectValue back to the definition of the MIB Object. > > And I finally understand that mibFieldOption is an Options Template. > > What is very confusing to me is that mibFieldOption is apparently simply an Options Template, like we have defined in IPFIX (http://tools.ietf.org/html/rfc7011#section-4.1) or PSAMP (http://tools.ietf.org/html/rfc5476#section-6.5.1) > However, this Options Template is called like an IPFIX IE: mibFieldOption > This should be called "MIB Field Options Template" throughout the document. > > OLD: > This document also defines three standard Option Templates (see > Section 4.2 ) that are used as part of the mechanism to export MIB > Object meta data: > > o mibFieldOption (Section 4.2.1 ) > > o mibSubFieldOption (Section 4.2.2 ) > > o mibTypeOption (Section 4.2.3 ) > > NEW: > This document also defines three standard Option Templates (see > Section 4.2 ) that are used as part of the mechanism to export MIB > Object meta data: > > o MIB Field Options Template (Section 4.2.1 ) > > o MIB SubField Options Template (Section 4.2.2 ) > > o MIB Type Options Template (Section 4.2.3 ) CM: I think I just wanted to give a handle/name to the particular option export, to make it clearer to refer to throughout the document. If it was more confusing that is bad. I've updated the names of the Options exports to match your suggestions. > > > - Major: Why do we have ... > http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1 > http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.2 > ... with slightly different specifications? > As I mentioned previously, there are also some conflicting spec rules at the beginning of the section 4 CM: I've removed the duplicate list of required fields and just added a reference to the required minimum section. There are now no spec rules or keywords in the initial part of this section. > > - > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 26 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 258 | Field Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope field count = 2 |0| IE = templateId | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0| IE = informationElementIndex| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0| IE = mibObjectIdentifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 65535 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 19: Example of tcpCurrEstab mibFieldOption Template Set > > This is not an Template Set, but an Options Template Set. > Same remark for all the examples. CM: I've checked and fixed the titles for all the examples > > - Section 4.2 > > Why a single in this sentence? > For each mibObjectValue field that is defined in an IPFIX Template, a > single mibFieldOption Data Record MUST be exported that provides the > required minimum information to define the MIB object that is being > exported (seeSection 4.2.1 ). > > What if we export with UDP? We might want to re-export this metadata information, without which the collector can't interpret the data. CM: Agreed - the point is we want to treat the Data Records with the OIDS like templates. Removed the single Updated to If Multiple MIB Field Options Data Records that refer to a mibObjectValue are received the latest MUST be used. > This contradicts: > Note that the ID of an identical mibFieldOptionTemplate which has > already been exported MAY be reused without exporting the Template > again. CM: Resolved > > - Section 4.2 > > This mibFieldOption Data is defined in a template referred to in this > document as a mibFieldOption Template with the format specified in > Section 4.4 . > > What's mibFieldOption Data? > Template -> Options Template CM: Updated to The MIB Field Options Data Records are defined in a template referred to in this document as a MIB Field Options Template with the format specified in . > > - Section 4.2 > > _ A Template that uses a mibObjectValue Field MUST be exported prior to > the corresponding mibFieldOption Data Records._ It is RECOMMENDED > that these are all exported in the same IPFIX Message. Note that > this places an implicit size constraint on the export. > > _ These MUST all be exported prior to the corresponding Data Records > which depend upon them._ i.e. referring to Figure 1, the export order > MUST be: > > The two underlined sentences are redundant. CM: Not quite. There are 2 different types of Data records in play here. The MIB Field Option Data Records contain the OIDs. The Object value data records contain values. This is saying that you need the oid data record before you can understand the values. I've reworded it as follows which is clearer: The MIB Field Options Template and MIB Field Options Data Records MUST be exported in the same IPFIX Message as any Template that is using a mibObjectValue Information Element. Note that this places an implicit size constraint on the export. This whole set of Templates and MIB Field Options Data Records MUST all be exported prior to the corresponding Data Records which depend upon them. i.e. referring to , the export order MUST be: Data Template for mibObjectValue Information Elements MIB Field Options Template MIB Field Options Data Records MIB Object Value Data Records > > - Major > While the following are optional, they are nevertheless RECOMMENDED > in certain circumstances as they are per field: > > You don't explain those circumstances CM: Added a reference for each of these optional IEs to the section that explains when to use them. > > - I arrived at section 4.3, I'm not clear when I need to use mibSubFieldOption ormibTypeOption > > For mibSubFieldOption, this only thing I read so far is: > To export a mibObjectValue that is contained in a > mibObjectValueSequence Field with a mibSubFieldOption three fields > are REQUIRED: > > Not too clear. CM: Agreed. The mibSubIdentifier usage is now part of the standard MIB Field Options Template. This is clearer. I've added a note on when to use the mibSubIdentifier and a reference to the correct section. The MIB Type Options Export is entierly optional. Since it is just RECOMMENDED I've taken all the fields together into 1 list. > > - Major, Section 4.4.1 > > Multiple > mibFieldOption that refer to a single mibObjectValue MUST NOT be > exported. > > What is Multiple mibFieldOption? > Multiple Data Records. No > Multiple different Data Records. I agree > Multiple Options Template Records. No > Multiple different Options Template Records. I agree CM: Reworded to match standard template behaviour on UDP - use the latest version: If Multiple MIB Field Options Data Records that refer to a mibObjectValue are received the latest MUST be used. This matches the expected behaviour of IPFIX Templates. > > - Major, Section 4.4.1 > > OLD: > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID | Field Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE = Existing IPFIX Field | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE = mibObjectValueInteger | Field Length (mib) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 5: IPFIX Template Set using mibObjectValue Field > > > NEW: > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID | Field Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE = Existing IPFIX Field | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE = | Field Length (mib) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 5: IPFIX Template Set using mibObjectValue Field > > Then you have to explain that could be > mibObjectValueInteger, > mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS, > mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime, > mibObjectValueUnsigned, mibObjectValueTable and > mibObjectValueSequence. CM: Done. > > > I stopped my review at section 4.4.2, but plenty of my feedback would apparently be equivalent for the rest of the draft. I've tried to apply each of your points throughout the document. Thanks, colin From nobody Fri Jul 4 14:14:20 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DDA1A049F; Fri, 4 Jul 2014 14:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgSPHlDVmtlF; Fri, 4 Jul 2014 14:14:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 577531B2E34; Fri, 4 Jul 2014 14:14:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704211409.8239.66720.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 14:14:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/72y5lwhSdALXdxvDiDBHBlOxEOI Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 21:14:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Exporting MIB Variables using the IPFIX Protocol Authors : Paul Aitken Benoit Claise Colin McDowall Juergen Schoenwaelder Filename : draft-ietf-ipfix-mib-variable-export-06.txt Pages : 76 Date : 2014-07-04 Abstract: This document specifies a way to complement IPFIX Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. An IPFIX Options Template and method are specified, which are used to export the extra information required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 14:20:18 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0131A001E for ; Fri, 4 Jul 2014 14:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED8X1oSoZOYR for ; Fri, 4 Jul 2014 14:20:10 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537831A0016 for ; Fri, 4 Jul 2014 14:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2068; q=dns/txt; s=iport; t=1404508810; x=1405718410; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5AD+CagxPTkbPRYxV7nv9Xpk2Q1c7uOg3842RoTB7s4=; b=PBibNmxwBH9xP3R4GYJHVHHUC3Ni6Eo+fEFFh8qd9P6wI+chIGbOtQbl QHwH014Qq/RRunC76nN5jpnCfgvFxVG7X2CyALS4ZdcLTXA9mI2cWmRxL yLjEN924UHUHP8QdN36wY489vj8454XVOwdwDBXkknid+7PQzkkG+GRGd s=; X-IronPort-AV: E=Sophos;i="5.01,603,1400025600"; d="scan'208";a="104717580" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Jul 2014 21:20:08 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s64LK8XW011393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2014 21:20:08 GMT Received: from [10.61.105.209] (dhcp-10-61-105-209.cisco.com [10.61.105.209]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s64LK78X023218; Fri, 4 Jul 2014 22:20:07 +0100 (BST) Message-ID: <53B71A79.8010102@cisco.com> Date: Fri, 04 Jul 2014 22:19:53 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20140704211409.8239.66720.idtracker@ietfa.amsl.com> In-Reply-To: <20140704211409.8239.66720.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/ZOLN35ukf8wHePZDtlcvDnzvrLo Cc: "ipfix-ads@tools.ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 21:20:14 -0000 Dear All, here is version 6 of the IPFIX MIB export draft, reworked according to all the WGLC feedback we received. Thanks, Colin and Paul On 04/07/2014 22:14, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > Title : Exporting MIB Variables using the IPFIX Protocol > Authors : Paul Aitken > Benoit Claise > Colin McDowall > Juergen Schoenwaelder > Filename : draft-ietf-ipfix-mib-variable-export-06.txt > Pages : 76 > Date : 2014-07-04 > > Abstract: > This document specifies a way to complement IPFIX Data Records with > Management Information Base (MIB) objects, avoiding the need to > define new IPFIX Information Elements for existing Management > Information Base objects that are already fully specified. > > An IPFIX Options Template and method are specified, which are used to > export the extra information required to fully describe Simple > Network Management Protocol (SNMP) MIB objects in IPFIX. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Sun Jul 6 19:34:14 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771DF1A00D6 for ; Sun, 6 Jul 2014 19:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7eQUJs0YNH6 for ; Sun, 6 Jul 2014 19:34:09 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC931A00C9 for ; Sun, 6 Jul 2014 19:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1404700449; x=1436236449; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ZO1H1XgmHVCzRq6erMq/TGxxAPevT77V+1nX8L6yiUE=; b=TbBwTXBwrF5n0qMtey+4YGlZqSjUWrFx8kXBCFABVWQQ4fDxQ0EQ+wIV RIYM8iTWeeOZlvzYLMnzzWFVX94YCHD690O8SYq21sx2NJoYlTvYKoDb9 EkpH+UOpn16u6OP6QwfET5+YgomtqhONlA1gWAWaspWTIKbegRt1zVJfh w=; X-IronPort-AV: E=Sophos;i="5.01,615,1399982400"; d="scan'208";a="262320516" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 07 Jul 2014 14:34:07 +1200 Message-ID: <53BA071D.3030700@auckland.ac.nz> Date: Mon, 07 Jul 2014 14:34:05 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/dUU1A4CzA8FDG8Ewv4Svq1Y1XFk Subject: [IPFIX] Please take a look at mib-variable-export-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 02:34:11 -0000 Hi all: mib-variable-export-06.txt is the last draft on our current charter. Colin and Paul have revised it after feedback during its WGLC. Please take another careful look at it and let us know whether it's ready to submit to IESG now, or whether it has any remaining issues. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From nobody Tue Jul 8 00:47:24 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296C11B2A3F; Mon, 7 Jul 2014 22:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuY2f-3hAFP8; Mon, 7 Jul 2014 22:02:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9FE1B2A3A; Mon, 7 Jul 2014 22:02:35 -0700 (PDT) X-AuditID: c1b4fb3a-f799e6d000005085-62-53bb7b6a48da Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D5.9A.20613.A6B7BB35; Tue, 8 Jul 2014 07:02:34 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.174.1; Tue, 8 Jul 2014 07:02:34 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E9F6A110294; Tue, 8 Jul 2014 08:02:33 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 880885880F; Tue, 8 Jul 2014 08:03:19 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A535452144; Tue, 8 Jul 2014 08:03:18 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F7941C16-AA4F-4385-B012-9E8A06B5266E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jari Arkko In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120770050255@MX15A.corp.emc.com> Date: Tue, 8 Jul 2014 01:02:30 -0400 Message-ID: <7420463E-DBC7-4737-8792-D8ED5C4EB174@ericsson.com> References: <8D3D17ACE214DC429325B2B98F3AE7120770050255@MX15A.corp.emc.com> To: "Black, David" , "ietf@trammell.ch" X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RjerenewwbQ30hZbD69lt7j66jOL xcaWd2wWx66+Zndg8ThyZDaLx5IlP5k8nuyfyRLAHMVlk5Kak1mWWqRvl8CVMXvpAdaCHwYV m+9/Ym1gXKDfxcjJISFgInHxbQsThC0mceHeejYQW0jgKKPEgV9aXYxcQPZ6Rolj17ayQjh7 GSUWbvzGBuGsY5RofL6ZEaJlHqPEo5+qIAlmgSmMEsvu72cFSfAKGEisW3wMrEhYwFri0qcp YDvYBLQkNi5fAGZzCvhI7OtvBrNZBFQkZiy5ANbLLJAp8alpHQvEHHuJxuntTBDLvCW+7dgA Vi8iECgx4eMDVogf5CVmtJ9gh7DVJK6e28QMUa8icevvWbYJjCKzkN03C8l9s8D2aUssW/ia GcI2kHja+YoVwjaVeH30I1SNtcSMXwfZIGxFiSndD9kXMLKvYhQtTi0uzk03MtJLLcpMLi7O z9PLSy3ZxAiMvoNbflvtYDz43PEQowAHoxIPr8KDXcFCrIllxZW5hxilOViUxHkXnpsXLCSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoHRtPB+4iT1y59vK32Z4L3yYcW9ZxG5pvx28kI/pwnx 3LD9v3VN8Nvrd57NM+Z33pz5rejy+y8K7kd5979t6/zMdUJMU2jWlxLerSFHCv4+nr76Xaw+ o6rEI6n306ckJro4e2Z23PZN55PM6VHZufpZYK+1PWMd344FHI+iFt0pnvZCXSwqM+y5Ektx RqKhFnNRcSIA2rSXf58CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/J6Kp5NGb5_ZrzJ7NJHwCwLQthw8 X-Mailman-Approved-At: Tue, 08 Jul 2014 00:47:23 -0700 Cc: "General Area Review Team \(gen-art@ietf.org\)" , "ipfix@ietf.org" Subject: Re: [IPFIX] Gen-ART review of draft-ietf-ipfix-text-adt-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 05:02:51 -0000 --Apple-Mail=_F7941C16-AA4F-4385-B012-9E8A06B5266E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the review and and changes, David and Brian. =46rom my = perspective this document is ready to move forward in this week=92s IESG = telechat. Jari --Apple-Mail=_F7941C16-AA4F-4385-B012-9E8A06B5266E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCBEUw ggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVs aWFTb25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4X DTA2MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv 1rLnfub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqT u3TT39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMc CYXRlobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUb Az2oFRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB /wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRh cC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2 MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb 8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXI v6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzY FSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67 OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3k MXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OY CMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAw OjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDgg VjMwHhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVy YSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5D uVdWPMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe 1X7/jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF4 6H1ibp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjgh XYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGj ggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7ga YqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0F BgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7Bgcq hXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20w cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkww DgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUE kUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDC fkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6b KuTPBH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHn tP+npjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPd OI5GtDYPMIIEqjCCA5KgAwIBAgIQTyXs3vXto5joAjtwrbnc3jANBgkqhkiG9w0BAQUFADA5MREw DwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxMB4X DTEzMDMwNDEzMjUyMVoXDTE2MDMwNDEzMjUxOVowYjERMA8GA1UECgwIRXJpY3Nzb24xEzARBgNV BAMMCkphcmkgQXJra28xEDAOBgNVBAUTB2xtZmphYXIxJjAkBgkqhkiG9w0BCQEWF2phcmkuYXJr a29AZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhwriyJIY5Bbz yZrfnFAjWFLMNc6O6Z6dw5HqexTVyrUymDobuwcFtGl3n+yc6tYcvzM85LJMotJlOJH4NHEqClEc iMw+gFvN17PXxM2aAPuv1ZUL1wSdQ9dS94zxQEQuh4Myyfy+eqvrEBkzZaDPu4Evz6xsmCYPYSZP t4Bo6zbwQqkRvSQUO659ytmlyiPOiWN6wxEpwwO43LEw12xFrVSOQw3AG8ULW/xHbQvInuyWQdBC ug/1n6IJETsMWSrLFnk888IjABXKkmq42EG6RQ0BWLw8lAQwTju7rsDF9HrcTYBcu9z2u/d4cSgH P9SkRncRm68xrt7bD2RhPf3rkQIDAQABo4IBgzCCAX8wgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3 aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZx bGRhcDovL2xkYXAudHJ1c3QudGVsaWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFs JTIwQ0EwMSxvPUVyaWNzc29uP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2Uw IgYDVR0RBBswGYEXamFyaS5hcmtrb0Blcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEw MTAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0O BBYEFLk/k+8oySkNxYm0GyPaFaKSRQufMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCb MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAECF65IiGH7GS+EEHre+itv2wv0OQ Z68DWR6G9IqMkBgb8dj6JcfFsu+9p8ID1e1L/0ybeTwz1t4IPhuOuWBPohj5irYiCBJkIokUr09B rWPyxfBrSoZ+uXVWfmZSdp15pWlEnHhuGuJkZ2a0MKrj+OEM9qfQR5Cvdlmx5PvsIhFkAFcZWldI xBwHsEeSoGJbVvvNImiY6M27u6rhuR8HanXVdcW4B8gK489LutxKhyhT9QDFUhmyWk2qYCUJgwM/ w44sLz8tv95jDbJxAR/aOwdwF3fQgj8VB5Xwvdn6B0PhfEcd3Ju4yUz6HE6ELZWG4ruE2haUCOn4 8WStKZ/RPDGCApMwggKPAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQTyXs3vXto5joAjtwrbnc3jAJBgUrDgMCGgUAoIIBGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA3MDgwNTAyMzFaMCMG CSqGSIb3DQEJBDEWBBS8EmCd+NCUJBw0sR2tjEYvQoJVrTBcBgkrBgEEAYI3EAQxTzBNMDkxETAP BgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l 7N717aOY6AI7cK253N4wXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQw IgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l7N717aOY6AI7cK253N4wDQYJ KoZIhvcNAQEBBQAEggEAHQjLnLg5AEkTY50JIIInk4CRlm4U11vHvgD/7KfYbbQrEu0lWIaua4jn OeDILB51qe7GZ73zK9c4DaA415x4DG2tXqhHamEzocwVvAZVyDqWk2mHf4cz9AQB29JH7AKmxIna Fbu2XHHW++NTEut+E3cH39W9NCS77+jx0xdvr4nOw2a3HvwwZfeEg+85YuRpy6LlHtwhvfJ8tww4 covCkiPRgSR5sumlOicaqHZSPIBxvJ6X3x+fCkaQYTcC5UbYEslYdL4dgKaopzMY69vc4UdPyGge dkHdlwwkbUA+khHRgN4ACe2pIp2GHjPeMRYP8vVpI18Lu9WXjHeK158GgwAAAAAAAA== --Apple-Mail=_F7941C16-AA4F-4385-B012-9E8A06B5266E-- From nobody Tue Jul 15 08:30:31 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB571B2883; Tue, 15 Jul 2014 08:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5aNQUkamaAQ; Tue, 15 Jul 2014 08:29:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF4D1A0A8A; Tue, 15 Jul 2014 08:29:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140715152917.31271.45346.idtracker@ietfa.amsl.com> Date: Tue, 15 Jul 2014 08:29:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/coY8fuDvK8Q0IOjpUQEdpd4o9G0 Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-text-adt-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 15:29:58 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Textual Representation of IPFIX Abstract Data Types Author(s) : B. Trammell Filename : draft-ietf-ipfix-text-adt Pages : 13 Date : 2014-07-15 This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-ipfix-text-adt-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-text-adt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-07-15082917.I-D@ietf.org> --NextPart-- From nobody Wed Jul 16 15:24:30 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1471A0384; Wed, 16 Jul 2014 15:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeGgXCXLW-Hu; Wed, 16 Jul 2014 15:24:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE401A0354; Wed, 16 Jul 2014 15:24:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140716222427.14473.7386.idtracker@ietfa.amsl.com> Date: Wed, 16 Jul 2014 15:24:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/1ZYf5gzrbB2kDMblROoJjf5o_UI Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:24:28 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Textual Representation of IPFIX Abstract Data Types' During the IESG telechat, the IESG concluded that this document should be Proposed Standard, and not Informational as initially proposed in v6. This IETF LC should focus on the Proposed Standard changes in the latest version. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jul 16 15:33:51 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1437F1A037D for ; Wed, 16 Jul 2014 15:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvwxGcpRaOWC for ; Wed, 16 Jul 2014 15:33:49 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CEEF1A0378 for ; Wed, 16 Jul 2014 15:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6773; q=dns/txt; s=iport; t=1405550029; x=1406759629; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=ernd1NoA+VVordaEOdngyC6O0lRkyxZdSfUPNwIT4Ds=; b=ltGowS32O104D+9kChE3h0+8T7ZO2gwuE/qmjFIbPaOuB+SONXsisDwu FzsV2DZ9u7RVDbcQKGDh1EHBvQet1kmP7D29U/nstwotvUyOaQTmwmniN VK2z3E3kBAQZqD3Yrphxy9BNxvk4ZUvTz7gw66ovr8zv5pdNwnnf0RYJP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEALz8xlOtJssW/2dsb2JhbABag2BXwy0BCYdCAYEhdoQDAQEBBAEBAWsKDQQcAwECChYECwkDAgECARUfBwIIBg0GAgEBiD4NylEXjzoYBoQ9BZsdgUyFSI0YggKBRDsv X-IronPort-AV: E=Sophos;i="5.01,674,1400025600"; d="scan'208,217";a="113918353" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 16 Jul 2014 22:33:47 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6GMXleq020747 for ; Wed, 16 Jul 2014 22:33:47 GMT Message-ID: <53C6FDCB.5030804@cisco.com> Date: Thu, 17 Jul 2014 00:33:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20140716222427.14473.7386.idtracker@ietfa.amsl.com> In-Reply-To: <20140716222427.14473.7386.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140716222427.14473.7386.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030607020901070705010905" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/JrMw9uHeALod13gTvvp4LxBoMcg Subject: [IPFIX] Fwd: Last Call: (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:33:51 -0000 This is a multi-part message in MIME format. --------------030607020901070705010905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear IPFIX WG, In the text below, I explain the reason behind the second IETF LC: During the IESG telechat, the IESG concluded that this document should be Proposed Standard, and not Informational as initially proposed in v6. This IETF LC should focus on the Proposed Standard changes in the latest version. Regards, Benoit -------- Original Message -------- Subject: [IPFIX] Last Call: (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard Date: Wed, 16 Jul 2014 15:24:27 -0700 From: The IESG Reply-To: To: IETF-Announce CC: The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Textual Representation of IPFIX Abstract Data Types' During the IESG telechat, the IESG concluded that this document should be Proposed Standard, and not Informational as initially proposed in v6. This IETF LC should focus on the Proposed Standard changes in the latest version. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix . --------------030607020901070705010905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear IPFIX WG,

In the text below, I explain the reason behind the second IETF LC:
During the IESG telechat, the IESG concluded that this document should be 
Proposed Standard, and not Informational as initially proposed in v6.
This IETF LC should focus on the Proposed Standard changes in the 
latest version.

Regards, Benoit

-------- Original Message --------
Subject: [IPFIX] Last Call: <draft-ietf-ipfix-text-adt-07.txt> (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard
Date: Wed, 16 Jul 2014 15:24:27 -0700
From: The IESG <iesg-secretary@ietf.org>
Reply-To: <ietf@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <ipfix@ietf.org> 


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Textual Representation of IPFIX Abstract Data Types'
  <draft-ietf-ipfix-text-adt-07.txt>

During the IESG telechat, the IESG concluded that this document should be 
Proposed Standard, and not Informational as initially proposed in v6.
This IETF LC should focus on the Proposed Standard changes in the 
latest version. 

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-07-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines UTF-8 representations for IPFIX abstract data
   types, to support interoperable usage of the IPFIX Information
   Elements with protocols based on textual encodings.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
.


--------------030607020901070705010905-- From nobody Thu Jul 17 07:05:25 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5B21A0AF2; Thu, 17 Jul 2014 07:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.901 X-Spam-Level: X-Spam-Status: No, score=-13.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Fd638ormapQ; Thu, 17 Jul 2014 07:05:17 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48CC1A0AE0; Thu, 17 Jul 2014 07:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13569; q=dns/txt; s=iport; t=1405605918; x=1406815518; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=px3Xc7HEVF9fLaMLPf/WBR3Od4Wi8ayNJ6K6QPKdarg=; b=l82aLn4nsNYJYEMkjg7BkZlxKX1NAQHslJuUHsj9LSJz49fJqYHnwohI 0SEuAfEr70ik8T8EMhQjIvch15ZQiJLdTzeyMwYS92u/IrNQZH6rBqMb4 Z6ThqIqSdgC4EJiW56rDnOpt+CfrJkdN6SfYGqJYmu5OROMBjxQ/7aobY 4=; X-IronPort-AV: E=Sophos;i="5.01,678,1400025600"; d="scan'208,217";a="115493832" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 17 Jul 2014 14:05:16 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6HE5ELk018122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2014 14:05:15 GMT Received: from [10.61.107.35] (dhcp-10-61-107-35.cisco.com [10.61.107.35]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s6HE5Dr3026248; Thu, 17 Jul 2014 15:05:13 +0100 (BST) Message-ID: <53C7D814.3030906@cisco.com> Date: Thu, 17 Jul 2014 15:05:08 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Benoit Claise References: <20140716222427.14473.7386.idtracker@ietfa.amsl.com> <53C6FDCB.5030804@cisco.com> In-Reply-To: <53C6FDCB.5030804@cisco.com> Content-Type: multipart/alternative; boundary="------------080702020301070805080506" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/UlFkMyc7CgaugBnlKd8QJxvRrOc Cc: "ietf@ietf.org" , "ipfix@ietf.org" , Brian Trammell Subject: Re: [IPFIX] Fwd: Last Call: (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 14:05:24 -0000 This is a multi-part message in MIME format. --------------080702020301070805080506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benoit, Brian, All, 4. Data Type Encodings Each subsection of this section defines a textual encoding for the abstract data types defined in [RFC7012]. Is 7012 the correct reference? Isn't IANA's IPFIX registry now understood to be the master reference? (ie, http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types) With a view to extensibility, this document doesn't say what to do if/when new data types are added to IANA (eg, see ietf-ipfix-mib-variable-export). eg even one line to say that they can be represented in a default or limited way, or that they cannot be represented at all - in which case, how should the representation be extended in future, if needs be? Appendix A / Figure 1: While Figure 1 in this draft initially seems identical to Figure 1 in section10.2 of 7013, there are some important differences between them: 7013: sourceIPv4Address(8)[4]{key} destinationIPv4Address(12)[4]{key} Figure 1: sourceIPv6Address(27)[4]{key} destinationIPv6Address(28)[4]{key} ... tcpControlBits(6)[1] flowEndReason(136)[1] This has been wrong since -00 : sourceIPv6Address(27)[4]{key} destinationIPv6Address(28)[4]{key} (Figure 2 shows a length of 16 for these, so presumably s/v4/v6/ and s/[4]/[16]/ in the above definitions.) And tcpControlBits: tcpControlBits(6)[1] - has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly. Figure 3: it's not clear how the strings for the timestamp, IPv6 address, and protocol identifier fields get mapped to the corresponding dateTimeMilliseconds, ipv6address, and unsigned8 types shown in Figures 1 and 2. eg, conversion is required between "tcp" and 6, so the draft should mention that. P. On 16/07/2014 23:33, Benoit Claise wrote: > Dear IPFIX WG, > > In the text below, I explain the reason behind the second IETF LC: > > During the IESG telechat, the IESG concluded that this document should be > Proposed Standard, and not Informational as initially proposed in v6. > This IETF LC should focus on the Proposed Standard changes in the > latest version. > > > Regards, Benoit > > -------- Original Message -------- > Subject: [IPFIX] Last Call: > (Textual Representation of IPFIX Abstract Data Types) to Proposed > Standard > Date: Wed, 16 Jul 2014 15:24:27 -0700 > From: The IESG > Reply-To: > To: IETF-Announce > CC: > > > > The IESG has received a request from the IP Flow Information Export WG > (ipfix) to consider the following document: > - 'Textual Representation of IPFIX Abstract Data Types' > > > During the IESG telechat, the IESG concluded that this document should be > Proposed Standard, and not Informational as initially proposed in v6. > This IETF LC should focus on the Proposed Standard changes in the > latest version. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-07-30. Exceptionally, comments may be > sent toiesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines UTF-8 representations for IPFIX abstract data > types, to support interoperable usage of the IPFIX Information > Elements with protocols based on textual encodings. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > . > > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------080702020301070805080506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Benoit, Brian, All,

4.  Data Type Encodings

   Each subsection of this section defines a textual encoding for the
   abstract data types defined in [RFC7012].

Is 7012 the correct reference? Isn't IANA's IPFIX registry now understood to be the master reference?
(ie, http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types)


With a view to extensibility, this document doesn't say what to do if/when new data types are added to IANA (eg, see ietf-ipfix-mib-variable-export).
eg even one line to say that they can be represented in a default or limited way, or that they cannot be represented at all -  in which case, how should the representation be extended in future, if needs be?


Appendix A / Figure 1:

While Figure 1 in this draft initially seems identical to Figure 1 in section10.2 of 7013, there are some important differences between them:

7013:
	 sourceIPv4Address(8)<ipv4Address>[4]{key}
	 destinationIPv4Address(12)<ipv4Address>[4]{key}
Figure 1:
         sourceIPv6Address(27)<ipv4Address>[4]{key}
         destinationIPv6Address(28)<ipv4Address>[4]{key}
	 ...
         tcpControlBits(6)<unsigned8>[1]
         flowEndReason(136)<unsigned8>[1]

This has been wrong since -00 :

         sourceIPv6Address(27)<ipv4Address>[4]{key}
         destinationIPv6Address(28)<ipv4Address>[4]{key}

(Figure 2 shows a length of 16 for these, so presumably s/v4/v6/ and s/[4]/[16]/ in the above definitions.)


And tcpControlBits:

         tcpControlBits(6)<unsigned8>[1]

- has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly.


Figure 3: it's not clear how the strings for the timestamp, IPv6 address, and protocol identifier fields get mapped to the corresponding dateTimeMilliseconds, ipv6address, and unsigned8 types shown in Figures 1 and 2. eg, conversion is required between "tcp" and 6, so the draft should mention that.


P.


On 16/07/2014 23:33, Benoit Claise wrote:
Dear IPFIX WG,

In the text below, I explain the reason behind the second IETF LC:
During the IESG telechat, the IESG concluded that this document should be 
Proposed Standard, and not Informational as initially proposed in v6.
This IETF LC should focus on the Proposed Standard changes in the 
latest version.

Regards, Benoit

-------- Original Message --------
Subject: [IPFIX] Last Call: <draft-ietf-ipfix-text-adt-07.txt> (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard
Date: Wed, 16 Jul 2014 15:24:27 -0700
From: The IESG <iesg-secretary@ietf.org>
Reply-To: <ietf@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <ipfix@ietf.org> 


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Textual Representation of IPFIX Abstract Data Types'
  <draft-ietf-ipfix-text-adt-07.txt>

During the IESG telechat, the IESG concluded that this document should be 
Proposed Standard, and not Informational as initially proposed in v6.
This IETF LC should focus on the Proposed Standard changes in the 
latest version. 

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-07-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines UTF-8 representations for IPFIX abstract data
   types, to support interoperable usage of the IPFIX Information
   Elements with protocols based on textual encodings.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
.






_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------080702020301070805080506-- From nobody Thu Jul 17 07:40:48 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3CB1AC0D2; Thu, 17 Jul 2014 07:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn1M3OpK0fgO; Thu, 17 Jul 2014 07:40:43 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6B01ABB33; Thu, 17 Jul 2014 07:40:43 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 4C5B01A032D; Thu, 17 Jul 2014 16:40:12 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_5E21C5D5-43E4-4518-95A5-599208EEA9BC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <53C7D814.3030906@cisco.com> Date: Thu, 17 Jul 2014 16:40:13 +0200 Message-Id: References: <20140716222427.14473.7386.idtracker@ietfa.amsl.com> <53C6FDCB.5030804@cisco.com> <53C7D814.3030906@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/jH5WNTW90KWZC6kr5Ssb2qK99_s Cc: "ietf@ietf.org" , "ipfix@ietf.org" Subject: Re: [IPFIX] Fwd: Last Call: (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 14:40:45 -0000 --Apple-Mail=_5E21C5D5-43E4-4518-95A5-599208EEA9BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 hi Paul, thanks for the comments/review. Commentcomments inline: On 17 Jul 2014, at 16:05, Paul Aitken wrote: > Benoit, Brian, All, >=20 > 4. Data Type Encodings >=20 >=20 > Each subsection of this section defines a textual encoding for the > abstract data types defined in [RFC7012]. >=20 >=20 > Is 7012 the correct reference? Isn't IANA's IPFIX registry now = understood to be the master reference? > (ie, = http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-elemen= t-data-types) For IEs, yes. This is a reference to the abstract data types defined in = section 3.1 of RFC 7012, not the Information Element definitions. > With a view to extensibility, this document doesn't say what to do = if/when new data types are added to IANA (eg, see = ietf-ipfix-mib-variable-export). > eg even one line to say that they can be represented in a default or = limited way, or that they cannot be represented at all - in which case, = how should the representation be extended in future, if needs be? I presume that this would have to be done by a future draft that updates = this RFC, referencing a draft that updates Section 3.1 of RFC 7012, but = we can say so explicitly. Note that every ADT that's been added or considered since RFC 5102 has = been more or less a hack that only makes sense within the binary = encoding, and as such doesn't need a text representation. The RFC 6313 = ADTs are only interesting in the context of the RFC 7101 encoding of the = ADTs, and are explicitly noted as such in section 4.11. mib-variable-export is a more interesting case, but I don't think it = really applies here. The point of this work is to allow interoperability = for textual representations of values for Information Elements taken = from the IPFIX Information Element registry. The point of = mib-variable-export is to allow IPFIX (or rather, the binary encoding of = records defined in RFC 7011, to which the representation is quite = tightly bound) to export Information Elements in a _different_ type = space. And most probably, the right way to do that would be to directly = define textual representations for MIB data directly (which I presume = already exist; I'm not by any stretch of the imagination an SNMP geek.)=20= > Appendix A / Figure 1: >=20 > While Figure 1 in this draft initially seems identical to Figure 1 in = section10.2 of 7013, there are some important differences between them: >=20 > 7013: > sourceIPv4Address(8)[4]{key} > destinationIPv4Address(12)[4]{key} >=20 > Figure 1: > sourceIPv6Address(27)[4]{key} > destinationIPv6Address(28)[4]{key} > ... > tcpControlBits(6)[1] > flowEndReason(136)[1] >=20 >=20 >=20 >=20 > This has been wrong since -00 : >=20 > sourceIPv6Address(27)[4]{key} > destinationIPv6Address(28)[4]{key} >=20 > (Figure 2 shows a length of 16 for these, so presumably s/v4/v6/ and = s/[4]/[16]/ in the above definitions.) Yep, thanks for the catch. > And tcpControlBits: >=20 > tcpControlBits(6)[1] >=20 > - has been revised to unsigned16 [RFC7125]. Changing this would also = make Figure 2 align more neatly. It'll probably still be exported as 1 byte everywhere, but the type is = indeed unsigned16 > Figure 3: it's not clear how the strings for the timestamp, IPv6 = address, and protocol identifier fields get mapped to the corresponding = dateTimeMilliseconds, ipv6address, and unsigned8 types shown in Figures = 1 and 2. eg, conversion is required between "tcp" and 6, so the draft = should mention that. It does: section 4.2, paragraph 2: In the special case that the unsigned Information Element has identifier semantics, and refers to a set of codepoints, either in an external registry, a sub-registry, or directly in the description of the Information Element, then the name or short description for that codepoint as a string MAY be used to improve readability. Thanks, cheers, Brian > On 16/07/2014 23:33, Benoit Claise wrote: >> Dear IPFIX WG, >>=20 >> In the text below, I explain the reason behind the second IETF LC: >> During the IESG telechat, the IESG concluded that this document = should be=20 >> Proposed Standard, and not Informational as initially proposed in v6. >> This IETF LC should focus on the Proposed Standard changes in the=20 >> latest version.=20 >>=20 >>=20 >> Regards, Benoit >>=20 >> -------- Original Message -------- >> Subject: [IPFIX] Last Call: = (Textual Representation of IPFIX Abstract Data Types) to Proposed = Standard >> Date: Wed, 16 Jul 2014 15:24:27 -0700 >> From: The IESG >> Reply-To: >> To: IETF-Announce >> CC: >>=20 >> The IESG has received a request from the IP Flow Information Export = WG >> (ipfix) to consider the following document: >> - 'Textual Representation of IPFIX Abstract Data Types' >> >>=20 >> During the IESG telechat, the IESG concluded that this document = should be=20 >> Proposed Standard, and not Informational as initially proposed in v6. >> This IETF LC should focus on the Proposed Standard changes in the=20 >> latest version.=20 >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >>=20 >> ietf@ietf.org >> mailing lists by 2014-07-30. Exceptionally, comments may be >> sent to=20 >> iesg@ietf.org >> instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> This document defines UTF-8 representations for IPFIX abstract = data >> types, to support interoperable usage of the IPFIX Information >> Elements with protocols based on textual encodings. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ >>=20 >>=20 >> IESG discussion can be tracked via >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/ >>=20 >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >> _______________________________________________ >> IPFIX mailing list >>=20 >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >> . >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPFIX mailing list >>=20 >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_5E21C5D5-43E4-4518-95A5-599208EEA9BC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTx+BNAAoJENt3nsOmbNJcX5AH/RCHlMAVQZOmG6Tefkj2z63y d3gq8SfgYqYIrFfOr8QLdLxtPrdFKJ1+83M7+dBo4h5lBgeBj/kzFEjLkIsAm+DC LshXtu46Ww/PPw0vrSrDAETRYJ7WqfUO7fk2m/SY5W+mK5Xod9aaSFlB+cW7BaMZ 37pscZUffMnqOHGAS3V31Idl8czI1E/SJVyMQJFjAtfHv3CYmrsp+CY20CMWWY+L 6BaQbYGo59nZWqmiY5Et6U9R9D5lXtSLMIjaXnUmsB37PbvfaRPD91L3N5kbmpTp 4gA46cUDoG67RzzfZ/4pXQGmj/xM12XtMPzu1Mhd5I7c0n/o1AOJnloviXrkyrA= =K8cZ -----END PGP SIGNATURE----- --Apple-Mail=_5E21C5D5-43E4-4518-95A5-599208EEA9BC-- From nobody Thu Jul 17 08:59:41 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66481A0033; Thu, 17 Jul 2014 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moZawFiVZ9-o; Thu, 17 Jul 2014 08:59:26 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1F31A0181; Thu, 17 Jul 2014 08:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7337; q=dns/txt; s=iport; t=1405612766; x=1406822366; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Xm0dICgtIEa5AuA0+tmFeYHVRVhfpchkmA17qvkDVm0=; b=YWC6X88NeArpxmiEq1Jxlb73gbdol/WVD+gpUTFmXW/aqU/kTp/wIZ77 E0PDNjwdsUS0U1BSwv0kI0DQULpQjMD1ZbYCC7R/WLgO+weAq3fQpsmLi 9ixZRosAhTOv+od5a1Ks2W1nAWSe4FS6FEjz8OwSUj2+dWjMZZbr0Hs4D w=; X-IronPort-AV: E=Sophos;i="5.01,679,1400025600"; d="scan'208";a="114951459" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 17 Jul 2014 15:59:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6HFxNQ3009311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2014 15:59:24 GMT Received: from [10.61.107.35] (dhcp-10-61-107-35.cisco.com [10.61.107.35]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s6HFxMnF003236; Thu, 17 Jul 2014 16:59:22 +0100 (BST) Message-ID: <53C7F2D4.2070107@cisco.com> Date: Thu, 17 Jul 2014 16:59:16 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Trammell References: <20140716222427.14473.7386.idtracker@ietfa.amsl.com> <53C6FDCB.5030804@cisco.com> <53C7D814.3030906@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/74NQGqad4ykd56vN8AuH2CmWDyA Cc: "ietf@ietf.org" , "ipfix@ietf.org" Subject: Re: [IPFIX] Fwd: Last Call: (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:59:28 -0000 Brian, please see inline. On 17/07/2014 15:40, Brian Trammell wrote: > hi Paul, > > thanks for the comments/review. Commentcomments inline: > > On 17 Jul 2014, at 16:05, Paul Aitken wrote: > >> Benoit, Brian, All, >> >> 4. Data Type Encodings >> >> >> Each subsection of this section defines a textual encoding for the >> abstract data types defined in [RFC7012]. >> >> >> Is 7012 the correct reference? Isn't IANA's IPFIX registry now understood to be the master reference? >> (ie, http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types) > For IEs, yes. This is a reference to the abstract data types defined in section 3.1 of RFC 7012, not the Information Element definitions. Sure, the definitions are irrelevant here. Notice that I linked the IE *data types* registry. >> With a view to extensibility, this document doesn't say what to do if/when new data types are added to IANA (eg, see ietf-ipfix-mib-variable-export). >> eg even one line to say that they can be represented in a default or limited way, or that they cannot be represented at all - in which case, how should the representation be extended in future, if needs be? > I presume that this would have to be done by a future draft that updates this RFC, referencing a draft that updates Section 3.1 of RFC 7012, but we can say so explicitly. > > Note that every ADT that's been added or considered since RFC 5102 has been more or less a hack that only makes sense within the binary encoding, and as such doesn't need a text representation. The RFC 6313 ADTs are only interesting in the context of the RFC 7101 encoding of the ADTs, and are explicitly noted as such in section 4.11. > > mib-variable-export is a more interesting case, but I don't think it really applies here. The point of this work is to allow interoperability for textual representations of values for Information Elements taken from the IPFIX Information Element registry. The point of mib-variable-export is to allow IPFIX (or rather, the binary encoding of records defined in RFC 7011, to which the representation is quite tightly bound) to export Information Elements in a _different_ type space. And most probably, the right way to do that would be to directly define textual representations for MIB data directly (which I presume already exist; I'm not by any stretch of the imagination an SNMP geek.) My point wasn't about MIBs per se; rather, about adding new data types. But brain-fart, the mib-export draft adds new semantics (not types) - so it's not a super example. However the point stands: mention extensibility at least briefly. Thanks, P. >> Appendix A / Figure 1: >> >> While Figure 1 in this draft initially seems identical to Figure 1 in section10.2 of 7013, there are some important differences between them: >> >> 7013: >> sourceIPv4Address(8)[4]{key} >> destinationIPv4Address(12)[4]{key} >> >> Figure 1: >> sourceIPv6Address(27)[4]{key} >> destinationIPv6Address(28)[4]{key} >> ... >> tcpControlBits(6)[1] >> flowEndReason(136)[1] >> >> >> >> >> This has been wrong since -00 : >> >> sourceIPv6Address(27)[4]{key} >> destinationIPv6Address(28)[4]{key} >> >> (Figure 2 shows a length of 16 for these, so presumably s/v4/v6/ and s/[4]/[16]/ in the above definitions.) > Yep, thanks for the catch. > >> And tcpControlBits: >> >> tcpControlBits(6)[1] >> >> - has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly. > It'll probably still be exported as 1 byte everywhere, but the type is indeed unsigned16 > >> Figure 3: it's not clear how the strings for the timestamp, IPv6 address, and protocol identifier fields get mapped to the corresponding dateTimeMilliseconds, ipv6address, and unsigned8 types shown in Figures 1 and 2. eg, conversion is required between "tcp" and 6, so the draft should mention that. > It does: section 4.2, paragraph 2: > > In the special case that the unsigned Information Element has > identifier semantics, and refers to a set of codepoints, either in an > external registry, a sub-registry, or directly in the description of > the Information Element, then the name or short description for that > codepoint as a string MAY be used to improve readability. > > Thanks, cheers, > > Brian > >> On 16/07/2014 23:33, Benoit Claise wrote: >>> Dear IPFIX WG, >>> >>> In the text below, I explain the reason behind the second IETF LC: >>> During the IESG telechat, the IESG concluded that this document should be >>> Proposed Standard, and not Informational as initially proposed in v6. >>> This IETF LC should focus on the Proposed Standard changes in the >>> latest version. >>> >>> >>> Regards, Benoit >>> >>> -------- Original Message -------- >>> Subject: [IPFIX] Last Call: (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard >>> Date: Wed, 16 Jul 2014 15:24:27 -0700 >>> From: The IESG >>> Reply-To: >>> To: IETF-Announce >>> CC: >>> >>> The IESG has received a request from the IP Flow Information Export WG >>> (ipfix) to consider the following document: >>> - 'Textual Representation of IPFIX Abstract Data Types' >>> >>> >>> During the IESG telechat, the IESG concluded that this document should be >>> Proposed Standard, and not Informational as initially proposed in v6. >>> This IETF LC should focus on the Proposed Standard changes in the >>> latest version. >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> >>> ietf@ietf.org >>> mailing lists by 2014-07-30. Exceptionally, comments may be >>> sent to >>> iesg@ietf.org >>> instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document defines UTF-8 representations for IPFIX abstract data >>> types, to support interoperable usage of the IPFIX Information >>> Elements with protocols based on textual encodings. >>> >>> >>> >>> >>> The file can be obtained via >>> >>> http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ >>> >>> >>> IESG discussion can be tracked via >>> >>> http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/ >>> >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> . >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From nobody Thu Jul 17 13:16:44 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64991A0149; Thu, 17 Jul 2014 13:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etMaEUhh3gvY; Thu, 17 Jul 2014 13:16:41 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id BA9D51A00AA; Thu, 17 Jul 2014 13:16:40 -0700 (PDT) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 81A061A0A41; Thu, 17 Jul 2014 22:16:08 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_842B33FB-510C-421F-89B0-8302FF26132A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <53C7F2D4.2070107@cisco.com> Date: Thu, 17 Jul 2014 22:16:04 +0200 Message-Id: References: <20140716222427.14473.7386.idtracker@ietfa.amsl.com> <53C6FDCB.5030804@cisco.com> <53C7D814.3030906@cisco.com> <53C7F2D4.2070107@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/KBVjPCEpcMj_HsgE2HBM2WKurk0 Cc: "ietf@ietf.org" , "ipfix@ietf.org" Subject: Re: [IPFIX] Fwd: Last Call: (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 20:16:43 -0000 --Apple-Mail=_842B33FB-510C-421F-89B0-8302FF26132A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 17 Jul 2014, at 17:59, Paul Aitken wrote: > Brian, please see inline. >=20 >=20 > On 17/07/2014 15:40, Brian Trammell wrote: >> hi Paul, >>=20 >> thanks for the comments/review. Commentcomments inline: >>=20 >> On 17 Jul 2014, at 16:05, Paul Aitken wrote: >>=20 >>> Benoit, Brian, All, >>>=20 >>> 4. Data Type Encodings >>>=20 >>>=20 >>> Each subsection of this section defines a textual encoding for = the >>> abstract data types defined in [RFC7012]. >>>=20 >>>=20 >>> Is 7012 the correct reference? Isn't IANA's IPFIX registry now = understood to be the master reference? >>> (ie, = http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-elemen= t-data-types) >> For IEs, yes. This is a reference to the abstract data types defined = in section 3.1 of RFC 7012, not the Information Element definitions. >=20 > Sure, the definitions are irrelevant here. Notice that I linked the IE = *data types* registry. Section 3.1 of RFC 7012 is still normative for the data types. At least = I can't find anything in 7012 that suggests otherwise. >>> With a view to extensibility, this document doesn't say what to do = if/when new data types are added to IANA (eg, see = ietf-ipfix-mib-variable-export). >>> eg even one line to say that they can be represented in a default or = limited way, or that they cannot be represented at all - in which case, = how should the representation be extended in future, if needs be? >> I presume that this would have to be done by a future draft that = updates this RFC, referencing a draft that updates Section 3.1 of RFC = 7012, but we can say so explicitly. >>=20 >> Note that every ADT that's been added or considered since RFC 5102 = has been more or less a hack that only makes sense within the binary = encoding, and as such doesn't need a text representation. The RFC 6313 = ADTs are only interesting in the context of the RFC 7101 encoding of the = ADTs, and are explicitly noted as such in section 4.11. >>=20 >> mib-variable-export is a more interesting case, but I don't think it = really applies here. The point of this work is to allow interoperability = for textual representations of values for Information Elements taken = from the IPFIX Information Element registry. The point of = mib-variable-export is to allow IPFIX (or rather, the binary encoding of = records defined in RFC 7011, to which the representation is quite = tightly bound) to export Information Elements in a _different_ type = space. And most probably, the right way to do that would be to directly = define textual representations for MIB data directly (which I presume = already exist; I'm not by any stretch of the imagination an SNMP geek.) >=20 > My point wasn't about MIBs per se; rather, about adding new data = types. Yep, point taken. > But brain-fart, the mib-export draft adds new semantics (not types) - = so it's not a super example. However the point stands: mention = extensibility at least briefly. Absolutely, will do. Thanks, cheers, Brian --Apple-Mail=_842B33FB-510C-421F-89B0-8302FF26132A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTyC8EAAoJENt3nsOmbNJc5fUH/R4Ciq1crW8t+ZXipsN0J+p9 9l3tx3hQwtU38RVXNqt0W0xLQkIYB26MbU6bW4Wxy+7OGFDjzpWGy9B484rlj0AZ Qr+u8hqLknT/QQziHYJpCpU2PAzNcXSZYhTdYip75SNW0Q/FU3SVff+Mz74cSjKN Myzfx4WMrvoaD16WSm4Wyiv/PiLIr7nX9VZXyEl5tqKVLBjN+N95FazOhdffydbK EkNr1oPTu9mTjyzU0X7tVt1r4AITcYcMgesBmC9DQ2CLmOFJ6FbmBfH8H97Um+c1 dLz16BDFhjxxr1aRM4cneEwBzbyFAcfftub+NTFnlsFm6Vz9a/PNCIzKGDrltts= =Nuao -----END PGP SIGNATURE----- --Apple-Mail=_842B33FB-510C-421F-89B0-8302FF26132A-- From nobody Thu Jul 17 23:38:18 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407D21A011E; Thu, 17 Jul 2014 18:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfli87-MviAf; Thu, 17 Jul 2014 18:35:24 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C961A0115; Thu, 17 Jul 2014 18:35:23 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6I1ZKjW012342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2014 21:35:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6I1ZKjW012342 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1405647322; bh=gxPF90v13dypxLCqQ0bztYMHxik=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=I5j2KkcwuyioUTt0ZXgH3ifAT9rg73+tdI/uILHpwu3vJIUuPvehXGa6X+5Dkm6+g N5l2Sm6HwWitxLjZT3rpvpciymVW9HatT9wm3q1pkdoHHzGz2sVyjq6sH2nFjzYrQ4 NbJP8FsplC4DTAW+tCcGY969dkSTsSGYhVk38Kqs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6I1ZKjW012342 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Thu, 17 Jul 2014 21:35:10 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6I1Z9tE026144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 21:35:09 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Thu, 17 Jul 2014 21:35:09 -0400 From: "Black, David" To: "ietf@trammell.ch" , "General Area Review Team (gen-art@ietf.org)" Date: Thu, 17 Jul 2014 21:35:07 -0400 Thread-Topic: Gen-ART review of draft-ietf-ipfix-text-adt-07 Thread-Index: Ac+iKIAhuGCFxwJyQF+bD6JdAwx7vQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71207783F61A0@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public, Resumes Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/6_DutFWrITvpGNMPeCbFOaylgdI X-Mailman-Approved-At: Thu, 17 Jul 2014 23:38:14 -0700 Cc: "Black, David" , "ietf@ietf.org" , "ipfix@ietf.org" Subject: [IPFIX] Gen-ART review of draft-ietf-ipfix-text-adt-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 01:35:27 -0000 In reviewing the changes in the draft for Proposed Standard status (vs. the prior Informational status), I found one small nit: In section 4.2: Otherwise, the values of Information Elements of an unsigned integer type may be represented either as unprefixed base-10 (decimal) strings, as base-16 (hexadecimal) strings prefixed by "0x", or as base-2 (binary) strings prefixed by "0b". In the 2nd line: "type may be represented" -> "type are represented" idnits 2.13.01 misinterpreted [WSP] in the ABNF for octetArray as a reference - the resulting warning should be ignored.=20 Thanks, --David > -----Original Message----- > From: Black, David > Sent: Tuesday, June 24, 2014 5:41 PM > To: Black, David; ietf@trammell.ch; General Area Review Team (gen- > art@ietf.org) > Cc: ietf@ietf.org; ipfix@ietf.org > Subject: Gen-ART review of draft-ietf-ipfix-text-adt-06 >=20 > With correct subject line this time ... >=20 > > -----Original Message----- > > From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Black, Dav= id > > Sent: Tuesday, June 24, 2014 5:14 PM > > To: ietf@trammell.ch; General Area Review Team (gen-art@ietf.org) > > Cc: ietf@ietf.org; ipfix@ietf.org > > Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ipfix-text-adt-05 > > > > The -06 version of this draft addresses all of the comments in the > > Gen-ART review of the -05 version. > > > > Nit: I suggest one minor clarification in the added text (insertion > > of the word "comparing" is the primary purpose of this change, feel > > free to edit to taste): > > > > OLD > > See > > [RFC6885] and [I-D.ietf-precis-framework] for more on the dangers of > > Unicode strings.. > > NEW > > See > > [RFC6885] and [I-D.ietf-precis-framework] for more on possible > > unexpected results and related risks in comparing Unicode strings. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Black, David > > > Sent: Friday, May 23, 2014 10:11 PM > > > To: ietf@trammell.ch; General Area Review Team (gen-art@ietf.org) > > > Cc: ipfix@ietf.org; ietf@ietf.org; Black, David > > > Subject: Gen-ART review of draft-ietf-ipfix-text-adt-05 > > > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > > Gen-ART, please see the FAQ at > > > > > > . > > > > > > Please resolve these comments along with any other Last Call comments > > > you may receive. > > > > > > Document: draft-ietf-ipfix-text-adt-05 > > > Reviewer: David L. Black > > > Review Date: May 23, 2014 > > > IETF LC End Date: May 28, 2014 > > > > > > Summary: This draft is on the right track, but has open issues > > > described in the review. > > > > > > This is a relatively short draft defining textual representations of > > > IPFIX data elements. It's clear and easy to read. > > > > > > I assume that all the ABNF has been checked. The open issues involve > > > use of Unicode. > > > > > > Minor issues: > > > > > > Section 4.7 string > > > > > > As Information Elements of the string type are simply UTF-8 encode= d > > > strings, they are represented directly, subject to the escaping an= d > > > encoding rules of the Enclosing Context. > > > > > > There's nothing "simply" about use of UTF-8 encoded strings :-). > > > > > > There appear to be no restrictions on Unicode codepoint usage and no > > > requirements for string normalization or other preparation either in = this > > > draft or RFC 7011. This can be a formula for all sorts of mischief, = so > > > some warnings about what's possible should be added somewhere - some = of > > > these comments may be raising Unicode concerns in RFC 7011 that would > > > be better addressed there. > > > > > > A general warning about unreliability of Unicode string comparison > > > is in order. This also applies if an identifier that is not limited > > > to ASCII characters is substituted for an integer as described in > > > Section 4.2. In addition, the concerns around visually similar > > > characters discussed in section 10.5 of the pr=E9cis framework draft > > > (draft-ietf-pr=E9cis-framework) apply; a short summary and pointer > > > to that section of that draft should suffice. > > > > > > Section 4.1.5 of the pr=E9cis framework draft warns against use of mi= xed- > > > direction Unicode strings, as "there is currently no widely accepted = and > > > implemented solution for the processing and safe display of mixed- > > > direction strings." That warning deserves repetition here. > > > > > > Lots of mischief is possible with non-printing and control characters= - > > > I would expect that the Enclosing Context contains sufficient restric= tions > > > on use of Unicode to deal with most of this concern, and would state = that > > > expectation. This comment is definitely specific to this draft. > > > > > > Nits/editorial comments: > > > > > > Section 4.4 float32 and float64 > > > > > > exponent =3D ( "e" / "E" ) [sign] 1*3DIGIT > > > > > > Please explain why no more than 3 digits are ever required. > > > > > > Section 4.8 dateTime* > > > > > > The '*' in the section title, dateTime* is clever, but it's meaning i= s not > > > obvious. I suggest "The dateTime Data Types" as a better section tit= le. > > > > > > Section 5 Security Considerations > > > > > > The security considerations for the IPFIX Protocol [RFC7011] apply= ; > > > this document presents no additional security considerations. > > > > > > That's ok, although adding a direct mention of the [UTF8-EXPLOIT] TR > > > cited in RFC 7011 would be helpful. > > > > > > idnits 2.13.01 warns that the JSON reference (RFC 4627) is obsolete, = and > > > needs to be replaced with one or two current RFC references. > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer > > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 2= 93-7786 > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Jul 31 15:39:33 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEB71A0135 for ; Thu, 31 Jul 2014 15:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.998 X-Spam-Level: ** X-Spam-Status: No, score=2.998 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_SPAM=2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdeHAdRRDlKg for ; Thu, 31 Jul 2014 15:39:22 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5991A0115 for ; Thu, 31 Jul 2014 15:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1406846362; x=1438382362; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=fjN2Kue+dTAdy228mVW+xxsauMpwOTlXzJY+vPStlG8=; b=VVaA9Ylk6RNwbRESoHOnaHdQ54MbnT5SIthWwsxs3CkOnv1qKgIhiNgQ S+MZthZR5x1kATQoZ0ApNSYgSlyxohgMpzR+P9GqzKCztPWlmmXj4aFAM D6H0LkP9yGZb2EeivGfiOZ+w60CAZ4JA2vuIx+c1oVXVztprgp/J3Mw6j 8=; X-IronPort-AV: E=Sophos;i="5.01,775,1399982400"; d="scan'208";a="266683062" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 01 Aug 2014 10:39:19 +1200 Message-ID: <53DAC595.4050103@auckland.ac.nz> Date: Fri, 01 Aug 2014 10:39:17 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IPFIX Working Group References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/Vrs5R-EW3qexQIrluben0VM1Czw Subject: [IPFIX] Fwd: Call for Papers -- PAM 2015 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:39:27 -0000 Hi IPFIX folk: Next year's PAM conference will be in New York, here's its CFP. Cheers, Nevil -------- Original Message -------- Subject: Call for Papers -- PAM 2015 Date: Thu, 31 Jul 2014 16:14:17 -0400 *Passive and Active Measurement Conference (PAM)* Abstract Registration Due: Sept. 25, 2014 (11:59pm PDT) Submission Deadline: *Oct. 2, 2014 (11:59pm PDT)* Notification: Nov. 21, 2014 Camera Ready Due: Dec. 19, 2014 (11:59pm PDT) Conference: *New York City, NY, March 19-20, 2015* URL: http://wan.poly.edu/pam2015/call-for-papers.html -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand