From nobody Sun May 4 04:25:45 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 A4FB11A0071; Sun, 4 May 2014 04:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 uD9GVtN8V5vs; Sun, 4 May 2014 04:25:39 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 18E5D1A006E; Sun, 4 May 2014 04:25:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id ED4DA10739C; Sun, 4 May 2014 13:25:33 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpFColNOe4qz; Sun, 4 May 2014 13:25:33 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id C663510738E; Sun, 4 May 2014 13:25:13 +0200 (CEST) Received: from HYDRA.office.hd ([169.254.4.134]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Sun, 4 May 2014 13:24:52 +0200 From: Juergen Quittek To: Benoit Claise , 'IESG Secretary' , 'IETF IPFIX Working Group' Thread-Topic: Write-up for draft-ietf-ipfix-text-adt-02 Thread-Index: Ac9ni3Ftg827/3tMRpyDnOTE5qGdjA== Date: Sun, 4 May 2014 11:24:52 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E87DACBECF@Hydra.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/dglYHK_0zvHIjHRFvoejRF3CMEU Cc: "joelja@bogus.com" Subject: [IPFIX] Write-up for draft-ietf-ipfix-text-adt-02 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: Sun, 04 May 2014 11:25:42 -0000 Dear Benoit and dear IESG Secretary, Below please find the write-up for draft-ietf-ipfix-text-adt-02. The draft is ready for forwarding to the IESG for publication as Internet S= tandard. Best regards, Juergen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Write-up for draft-ietf-ipfix-text-adt-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the ti= tle page header? Informational. The header indicates: "Category: Informational". The document defines a textual representation of IPFIX information=20 elements. This is not needed for the IPFIX protocol operation, but provides a human-readable representations and allows exchange with other protocols. However, since no concrete translation and interoperability use case is addressed, this document is targeting at an Informational RFC.=20 (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved doc= uments. The approval announcement contains the following sections: Technical Summary: 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. Working Group Summary: The WG has consensus that this document is useful and has discussed=20 and reviewed it. There is strong consensus on the document. Document Quality: It is a short document with clear structure and clear definitions. The WG has reviewed it at WGLC and received comments have been=20 addressed. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Juergen Quittek is the document shepherd. Benoit Claise is the responsible Area Director. (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed the draft and is fully convinced that it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? During WG last call the document received reviews from key WG members. Several comments were made and have been addressed when updating=20 the document after the reviews. The shepherd has no concern about the=20 depth or breadth of the reviews. (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. There are no such issues. (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why? Yes. =20 (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures filed. (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? The WG as a whole understands and agrees with it. (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet- Drafts Checklist)= . Boilerplate checks are not enough; this check needs to be thorough. There are no nits. =20 (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. There is no further formal review required. (13) Have all references within this document been identified as either nor= mative or informative? Yes. (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? No. (15) Are there downward normative references (see RFC 3967)? If so, list th= ese downward references to support the Area Director in the Last Call proce= dure. No. (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. No. (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any= referenced IANA registries have been clearly identified. Confirm that newl= y created IANA registries include a detailed specification of the initial c= ontents for the registry, that allocations procedures for future registrati= ons are defined, and a reasonable name for the new registry has been sugges= ted (see RFC 5226). There IANA considerations section states that there is no IANA considerat= ion required for this document. =20 (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. There are no new IANA registries requested by this document. (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. I checked ABNF that is used for formally describing encodings.=20 All discovered issues have been fixed by the author.=20 From nobody Fri May 9 15:41:12 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 4EFA71A0102 for ; Fri, 9 May 2014 15:41:09 -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 isgUhdDnyrpY for ; Fri, 9 May 2014 15:41:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E7ABC1A010C for ; Fri, 9 May 2014 15:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9720; q=dns/txt; s=iport; t=1399675262; x=1400884862; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=UZ12+fLKumrvTB76Bo3wPwp500tAd3WQLJcdO7YYWbY=; b=QBAk0yeIyXT2+qjft2Nn6tLrPl3/rJ4tvegsEhyO94kZRbYAffJkrNMw IX62JbGEQywi/2t9cv++lzgc9Y1O+VOsE5AI7W/QnPG6+Qh2VrhqsL5Mj 2X5ElS0S+vAfMVNrYwfY7wyzU6/GtPrMV5xhxkHZ0SdnSyz/BbTv1FmYO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFABVZbVOtJA2G/2dsb2JhbABPCoMGT8YrAYEaFnSCJgEBBCdiLCUPAkYGDQgBAYg9DdEOF412Y4RABIV4hBaPOYE8hSmMHYNUHzA X-IronPort-AV: E=Sophos;i="4.97,1020,1389744000"; d="scan'208,217";a="323804975" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 09 May 2014 22:41:00 +0000 Received: from [10.82.237.219] (rtp-vpn5-1494.cisco.com [10.82.237.219]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s49MegJP024754 for ; Fri, 9 May 2014 22:40:45 GMT Message-ID: <536D5966.90609@cisco.com> Date: Fri, 09 May 2014 17:40:38 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <536D44FF.5060305@claise.be> In-Reply-To: <536D44FF.5060305@claise.be> X-Forwarded-Message-Id: <536D44FF.5060305@claise.be> Content-Type: multipart/alternative; boundary="------------050905050007090105000304" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/YmLkPLxkz4mYyehjW5yJeUTBYWE Subject: [IPFIX] AD review: draft-trammell-ipfix-text-adt 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, 09 May 2014 22:41:09 -0000 This is a multi-part message in MIME format. --------------050905050007090105000304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Below is my AD review - However, present and future operations and management protocols and applications may use textual encodings, and generic framing and structure as in JSON or XML. Please add references - A definition of canonical textual encodings for the IPFIX abstract data types would allow this set of Information Elements to be used for such applications, and for these applications to interoperate with IPFIX applications at the Information Element definition level. Note that templating or other mechanisms for data description for _such applications and protocols_ are application specific, and therefore out of scope for this document: only Information Element identification and data value representation are defined here. "such applications" don't refer to IPFIX applications from the previous paragraph - Note that templating or other mechanisms for data description for such applications and protocols are application specific, and therefore out of scope for this document:_only Information Element identification and data value representation are defined here. _ and Enclosing Context Textual representation of IPFIX data values is applied to use the IPFIX Information Model within some existing textual format (e.g. XML, JSON). This outer format is referred to as the Enclosing Context within this document. Enclosing Contexts define escaping and quoting rules for represented data values. what is "data value"? It should be Information Element value - Leading zeroes are allowed in any either encoding, and do not signify base-8 (octal) encoding. Binary encoding is intended for use with Information Elements with flag semantics, but can be used in any case. I guess you mean the "binary representation of unsigned" - Why should and not must? Instead, applications using textual representations of Information Elements should use Information Element names to identify them; see Appendix A for examples illustrating this principle. - btw, I found the RFC 2119 keywords in http://tools.ietf.org/id/draft-trammell-ipfix-text-adt-03.txt more appropriate, so that implementations could be compliant with this future RFC. However, I could live with that. Let's see what the other ADs will say. - Otherwise, the values of Information Elements of signed integer types should be represented as optionally-prefixed base-10 (decimal) strings. should be -> must? You are not consistent in the 4.X sections. For example, in 4.4: Otherwise, the values of Information Elements of float32 or float64 types_are represented_ as an optionally sign-prefixed, optionally base-10 exponent-suffixed, floating point decimal number. - If the Enclosing Context defines a representation for binary objects, that representation should be used. The should is weird. If it's a should, you should specify the exception(s). Otherwise, it's a must. Anyway, you had to make it clear when someone is compliant with this spec. Btw, why do you always need this sentence in 4.x? - I don't think it's appropriate to have [iana-ipfix-assignments] as a normative reference. In RFC7011 and RFC7012, it is informative - If figure 2 is the IPFIX Message, it should follow the same format as the RFC 7011 appendix examples. Then people will be able to compare. - change "Figure 2: IPFIX message containing sample flow" to "Figure 2: IPFIX Message containing sample Flow Records change "A Message containing this Template and a Data Record is shown in Figure 2" to "An IPFIX Message containing this Template and a Data Record is shown in Figure 2" - OLD: A Message containing this Template and a Data Record is shown in Figure 2, and a corresponding JSON Object using the text format defined in this document is shown in Figure 3. NEW: An_IPFIX_Message containing this Template and a Data Record is shown in Figure 2, and a corresponding JSON Object using the text format defined in this document is shown in Figure 3. Regards, Benoit --------------050905050007090105000304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Below is my AD review
-
  However, present and future operations and management protocols and
   applications may use textual encodings, and generic framing and
   structure as in JSON or XML. 

Please add references

-
 A definition of canonical textual
   encodings for the IPFIX abstract data types would allow this set of
   Information Elements to be used for such applications, and for these
   applications to interoperate with IPFIX applications at the
   Information Element definition level.

   Note that templating or other mechanisms for data description for
   such applications and protocols are application specific, and
   therefore out of scope for this document: only Information Element
   identification and data value representation are defined here.

"such applications" don't refer to IPFIX applications from the previous paragraph

- 

Note that templating or other mechanisms for data description for
   such applications and protocols are application specific, and
   therefore out of scope for this document: only Information Element
   identification and data value representation are defined here.


and 


 Enclosing Context
      Textual representation of IPFIX data values is applied to use the
      IPFIX Information Model within some existing textual format (e.g.
      XML, JSON).  This outer format is referred to as the Enclosing
      Context within this document.  Enclosing Contexts define escaping
      and quoting rules for represented data values.

what is "data value"? It should be Information Element value

-  Leading zeroes are allowed in any either encoding, and do not signify
   base-8 (octal) encoding.  Binary encoding is intended for use with
   Information Elements with flag semantics, but can be used in any
   case.

I guess you mean the "binary representation of unsigned"


 - Why should and not must?
   Instead, applications using textual representations of Information
   Elements should use Information Element names to identify them; see
   Appendix A for examples illustrating this principle.


- btw, I found the RFC 2119 keywords in http://tools.ietf.org/id/draft-trammell-ipfix-text-adt-03.txt more appropriate, so that implementations could be compliant with this future RFC.
However, I could live with that. Let's see what the other ADs will say.

- 
Otherwise, the values of Information Elements of signed integer types
   should be represented as optionally-prefixed base-10 (decimal)
   strings.
should be -> must?
You are not consistent in the 4.X sections. For example, in 4.4: 
   Otherwise, the values of Information Elements of float32 or float64
   types are represented as an optionally sign-prefixed, optionally
   base-10 exponent-suffixed, floating point decimal number.


- 
   If the Enclosing Context defines a representation for binary objects,
   that representation should be used.

The should is weird. If it's a should, you should specify the exception(s).
Otherwise, it's a must. 
Anyway, you had to make it clear when someone is compliant with this spec.
Btw, why do you always need this sentence in 4.x?


- 
I don't think it's appropriate to have [iana-ipfix-assignments] as a normative reference.
In RFC7011 and RFC7012, it is informative


- If figure 2 is the IPFIX Message, it should follow the same format as the RFC 7011 appendix examples.
Then people will be able to compare. 
 
- change "Figure 2: IPFIX message containing sample flow" to "Figure 2: IPFIX Message containing sample Flow Records
change 
   "A Message containing this Template and a Data Record
   is shown in Figure 2"
to 
   "An IPFIX Message containing this Template and a Data Record
   is shown in Figure 2"

-
OLD:
   A Message containing this Template and a Data Record
   is shown in Figure 2, and a corresponding JSON Object using the text
   format defined in this document is shown in Figure 3.

NEW:

   An IPFIX Message containing this Template and a Data Record
   is shown in Figure 2, and a corresponding JSON Object using the text
   format defined in this document is shown in Figure 3.


Regards, Benoit


--------------050905050007090105000304-- From nobody Wed May 14 06:30:35 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 CCF791A00D1; Wed, 14 May 2014 06:30:32 -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 hbNlCF_cRzwr; Wed, 14 May 2014 06:30:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C66E11A008A; Wed, 14 May 2014 06:30:31 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140514133031.16345.27920.idtracker@ietfa.amsl.com> Date: Wed, 14 May 2014 06:30:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/M2SDe3ngFndGu2NeNsMNZpZpA5U Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-05.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: Wed, 14 May 2014 13:30:33 -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 : Textual Representation of IPFIX Abstract Data Types Author : Brian Trammell Filename : draft-ietf-ipfix-text-adt-05.txt Pages : 12 Date : 2014-05-14 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-05 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 Wed May 14 10:03:53 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 074071A029F for ; Wed, 14 May 2014 10:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.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, 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 Cb7Dkt0nE5Kb for ; Wed, 14 May 2014 10:03:49 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 063321A0109 for ; Wed, 14 May 2014 10:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11531; q=dns/txt; s=iport; t=1400087022; x=1401296622; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=oKzTvgh2mz0MAJGDYfkDIWQ3Ud4TpBl0a+jLRjWMkRU=; b=RY3Szpo04yZGdMBIGJWbZUknTd912Y75BQCdlZSFwcBsfK5H8Oskv8u3 qtmAWUHinmGA8svrMV0tDPdFQOX0jrFbgnh8yF9o/u7VEbiyykBXdkI/5 TxQE72YMQkPIcGyo77oUtvIlIrsSCbAooBa7PmrxePjBdIL36YH3QtUEq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAFuhc1OtJV2a/2dsb2JhbABPCoMGT78MAYc6AYEjFnSCJgEBBAEBASRHChELIRYPCQMCAQIBFTAGAQwGAgEBiD0N0SAXjXJjhEAEhXiEGY9AgT2FLIwrg1YdMA X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208,217";a="43810564" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 14 May 2014 17:03:41 +0000 Received: from [10.21.94.78] (sjc-vpn5-1614.cisco.com [10.21.94.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4EH3fSG013453; Wed, 14 May 2014 17:03:41 GMT Message-ID: <5373A1ED.2070000@cisco.com> Date: Wed, 14 May 2014 10:03:41 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "ipfix@ietf.org" , Brian Trammell References: <536D44FF.5060305@claise.be> <536D5966.90609@cisco.com> In-Reply-To: <536D5966.90609@cisco.com> Content-Type: multipart/alternative; boundary="------------010200060500030306000702" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/kVouQJfejhehC84AqjFxtJfaoQ4 Subject: Re: [IPFIX] AD review: draft-trammell-ipfix-text-adt 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, 14 May 2014 17:03:52 -0000 This is a multi-part message in MIME format. --------------010200060500030306000702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Brian, Thanks for the new version 5 of the draft. One small editorial point. You correctly mention the references "XML [W3C-XML], JSON [RFC4627])" later in the text, but forgot the XML reference in the intro. See "JSON [RFC4627] or XML". Please correct that in your temp version. The draft is now sent to the IETF LC. Regards, Benoit > Brian, > > Below is my AD review > - > However, present and future operations and management protocols and > applications may use textual encodings, and generic framing and > structure as in JSON or XML. > > Please add references > > - > A definition of canonical textual > encodings for the IPFIX abstract data types would allow this set of > Information Elements to be used for such applications, and for these > applications to interoperate with IPFIX applications at the > Information Element definition level. > > Note that templating or other mechanisms for data description for > _such applications and protocols_ are application specific, and > therefore out of scope for this document: only Information Element > identification and data value representation are defined here. > > "such applications" don't refer to IPFIX applications from the previous paragraph > > - > > Note that templating or other mechanisms for data description for > such applications and protocols are application specific, and > therefore out of scope for this document:_only Information Element > identification and data value representation are defined here. > _ > > and > > > Enclosing Context > Textual representation of IPFIX data values is applied to use the > IPFIX Information Model within some existing textual format (e.g. > XML, JSON). This outer format is referred to as the Enclosing > Context within this document. Enclosing Contexts define escaping > and quoting rules for represented data values. > > what is "data value"? It should be Information Element value > > - Leading zeroes are allowed in any either encoding, and do not signify > base-8 (octal) encoding. Binary encoding is intended for use with > Information Elements with flag semantics, but can be used in any > case. > > I guess you mean the "binary representation of unsigned" > > > - Why should and not must? > Instead, applications using textual representations of Information > Elements should use Information Element names to identify them; see > Appendix A for examples illustrating this principle. > > - btw, I found the RFC 2119 keywords inhttp://tools.ietf.org/id/draft-trammell-ipfix-text-adt-03.txt more appropriate, so that implementations could be compliant with this future RFC. > However, I could live with that. Let's see what the other ADs will say. > > - > Otherwise, the values of Information Elements of signed integer types > should be represented as optionally-prefixed base-10 (decimal) > strings. > > should be -> must? > You are not consistent in the 4.X sections. For example, in 4.4: > > Otherwise, the values of Information Elements of float32 or float64 > types_are represented_ as an optionally sign-prefixed, optionally > base-10 exponent-suffixed, floating point decimal number. > > - > If the Enclosing Context defines a representation for binary objects, > that representation should be used. > > The should is weird. If it's a should, you should specify the exception(s). > Otherwise, it's a must. > Anyway, you had to make it clear when someone is compliant with this spec. > Btw, why do you always need this sentence in 4.x? > > > - > I don't think it's appropriate to have [iana-ipfix-assignments] as a normative reference. > In RFC7011 and RFC7012, it is informative > > > - If figure 2 is the IPFIX Message, it should follow the same format as the RFC 7011 appendix examples. > Then people will be able to compare. > > - change "Figure 2: IPFIX message containing sample flow" to "Figure 2: IPFIX Message containing sample Flow Records > change > "A Message containing this Template and a Data Record > is shown in Figure 2" > to > "An IPFIX Message containing this Template and a Data Record > is shown in Figure 2" > > - > OLD: > A Message containing this Template and a Data Record > is shown in Figure 2, and a corresponding JSON Object using the text > format defined in this document is shown in Figure 3. > > NEW: > > An_IPFIX_Message containing this Template and a Data Record > is shown in Figure 2, and a corresponding JSON Object using the text > format defined in this document is shown in Figure 3. > > > Regards, Benoit > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------010200060500030306000702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Brian,

Thanks for the new version 5 of the draft.

One small editorial point.
You correctly mention the references "XML [W3C-XML], JSON [RFC4627])" later in the text, but forgot the XML reference in the intro. See "JSON [RFC4627] or XML".
Please correct that in your temp version.

The draft is now sent to the IETF LC.

Regards, Benoit
Brian,

Below is my AD review
-
  However, present and future operations and management protocols and
   applications may use textual encodings, and generic framing and
   structure as in JSON or XML. 

Please add references

-
 A definition of canonical textual
   encodings for the IPFIX abstract data types would allow this set of
   Information Elements to be used for such applications, and for these
   applications to interoperate with IPFIX applications at the
   Information Element definition level.

   Note that templating or other mechanisms for data description for
   such applications and protocols are application specific, and
   therefore out of scope for this document: only Information Element
   identification and data value representation are defined here.

"such applications" don't refer to IPFIX applications from the previous paragraph

- 

Note that templating or other mechanisms for data description for
   such applications and protocols are application specific, and
   therefore out of scope for this document: only Information Element
   identification and data value representation are defined here.


and 


 Enclosing Context
      Textual representation of IPFIX data values is applied to use the
      IPFIX Information Model within some existing textual format (e.g.
      XML, JSON).  This outer format is referred to as the Enclosing
      Context within this document.  Enclosing Contexts define escaping
      and quoting rules for represented data values.

what is "data value"? It should be Information Element value

-  Leading zeroes are allowed in any either encoding, and do not signify
   base-8 (octal) encoding.  Binary encoding is intended for use with
   Information Elements with flag semantics, but can be used in any
   case.

I guess you mean the "binary representation of unsigned"


 - Why should and not must?
   Instead, applications using textual representations of Information
   Elements should use Information Element names to identify them; see
   Appendix A for examples illustrating this principle.


- btw, I found the RFC 2119 keywords in http://tools.ietf.org/id/draft-trammell-ipfix-text-adt-03.txt more appropriate, so that implementations could be compliant with this future RFC.
However, I could live with that. Let's see what the other ADs will say.

- 
Otherwise, the values of Information Elements of signed integer types
   should be represented as optionally-prefixed base-10 (decimal)
   strings.
should be -> must?
You are not consistent in the 4.X sections. For example, in 4.4: 
   Otherwise, the values of Information Elements of float32 or float64
   types are represented as an optionally sign-prefixed, optionally
   base-10 exponent-suffixed, floating point decimal number.


- 
   If the Enclosing Context defines a representation for binary objects,
   that representation should be used.

The should is weird. If it's a should, you should specify the exception(s).
Otherwise, it's a must. 
Anyway, you had to make it clear when someone is compliant with this spec.
Btw, why do you always need this sentence in 4.x?


- 
I don't think it's appropriate to have [iana-ipfix-assignments] as a normative reference.
In RFC7011 and RFC7012, it is informative


- If figure 2 is the IPFIX Message, it should follow the same format as the RFC 7011 appendix examples.
Then people will be able to compare. 
 
- change "Figure 2: IPFIX message containing sample flow" to "Figure 2: IPFIX Message containing sample Flow Records
change 
   "A Message containing this Template and a Data Record
   is shown in Figure 2"
to 
   "An IPFIX Message containing this Template and a Data Record
   is shown in Figure 2"

-
OLD:
   A Message containing this Template and a Data Record
   is shown in Figure 2, and a corresponding JSON Object using the text
   format defined in this document is shown in Figure 3.

NEW:

   An IPFIX Message containing this Template and a Data Record
   is shown in Figure 2, and a corresponding JSON Object using the text
   format defined in this document is shown in Figure 3.


Regards, Benoit





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

--------------010200060500030306000702-- From nobody Wed May 14 11:19:12 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 9DB181A012F; Wed, 14 May 2014 11:19:06 -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 srjOFZAJeLI7; Wed, 14 May 2014 11:19:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1161A0116; Wed, 14 May 2014 11:19:04 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140514181904.5778.6448.idtracker@ietfa.amsl.com> Date: Wed, 14 May 2014 11:19:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/Ad8tZdbYZ_G99Ym-lT8I24pwNnU Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Textual Representation of IPFIX Abstract Data Types) to Informational RFC 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, 14 May 2014 18:19:06 -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' as Informational RFC 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-05-28. 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 Thu May 15 02:42: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 372021A048C for ; Thu, 15 May 2014 02:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 KYIAEgOKEy0b for ; Thu, 15 May 2014 02:42:16 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375A91A0479 for ; Thu, 15 May 2014 02:42:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 28666D9305; Thu, 15 May 2014 11:42:07 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CIcx16hP+z5o; Thu, 15 May 2014 11:42:06 +0200 (MEST) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 7D44ED9304; Thu, 15 May 2014 11:42:06 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_EE43C08A-A8EF-4C91-A896-D89719EFF00F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Trammell In-Reply-To: <5373A1ED.2070000@cisco.com> Date: Thu, 15 May 2014 11:42:05 +0200 Message-Id: <2808F530-6059-46A3-9BDE-95689FAF69CC@tik.ee.ethz.ch> References: <536D44FF.5060305@claise.be> <536D5966.90609@cisco.com> <5373A1ED.2070000@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/w_E5oiHQKVF1A_OMnZiDKEcV2bs Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] AD review: draft-trammell-ipfix-text-adt 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, 15 May 2014 09:42:20 -0000 --Apple-Mail=_EE43C08A-A8EF-4C91-A896-D89719EFF00F Content-Type: multipart/alternative; boundary="Apple-Mail=_317103DD-5F99-42E0-AC96-D885931A272A" --Apple-Mail=_317103DD-5F99-42E0-AC96-D885931A272A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 hi Benoit, On 14 May 2014, at 19:03, Benoit Claise wrote: > Hi Brian, >=20 > Thanks for the new version 5 of the draft. >=20 > One small editorial point. > You correctly mention the references "XML [W3C-XML], JSON [RFC4627])" = later in the text, but forgot the XML reference in the intro. See "JSON = [RFC4627] or XML". Oops, thanks for the catch. > Please correct that in your temp version. Already done. > The draft is now sent to the IETF LC. Thanks, cheers, Brian > Regards, Benoit >> Brian, >>=20 >> Below is my AD review >> - >> However, present and future operations and management protocols and >> applications may use textual encodings, and generic framing and >> structure as in JSON or XML.=20 >>=20 >> Please add references >>=20 >> - >> A definition of canonical textual >> encodings for the IPFIX abstract data types would allow this set = of >> Information Elements to be used for such applications, and for = these >> applications to interoperate with IPFIX applications at the >> Information Element definition level. >>=20 >> Note that templating or other mechanisms for data description for >> such applications and protocols are application specific, and >> therefore out of scope for this document: only Information Element >> identification and data value representation are defined here. >>=20 >> "such applications" don't refer to IPFIX applications from the = previous paragraph >>=20 >> -=20 >>=20 >> Note that templating or other mechanisms for data description for >> such applications and protocols are application specific, and >> therefore out of scope for this document: only Information Element >> identification and data value representation are defined here. >>=20 >>=20 >> and=20 >>=20 >>=20 >> Enclosing Context >> Textual representation of IPFIX data values is applied to use = the >> IPFIX Information Model within some existing textual format = (e.g. >> XML, JSON). This outer format is referred to as the Enclosing >> Context within this document. Enclosing Contexts define = escaping >> and quoting rules for represented data values. >>=20 >> what is "data value"? It should be Information Element value >>=20 >> - Leading zeroes are allowed in any either encoding, and do not = signify >> base-8 (octal) encoding. Binary encoding is intended for use with >> Information Elements with flag semantics, but can be used in any >> case. >>=20 >> I guess you mean the "binary representation of unsigned" >>=20 >>=20 >> - Why should and not must? >> Instead, applications using textual representations of Information >> Elements should use Information Element names to identify them; = see >> Appendix A for examples illustrating this principle. >>=20 >> - btw, I found the RFC 2119 keywords in = http://tools.ietf.org/id/draft-trammell-ipfix-text-adt-03.txt more = appropriate, so that implementations could be compliant with this future = RFC. >> However, I could live with that. Let's see what the other ADs will = say. >>=20 >> -=20 >> Otherwise, the values of Information Elements of signed integer types >> should be represented as optionally-prefixed base-10 (decimal) >> strings. >>=20 >> should be -> must?=20 >> You are not consistent in the 4.X sections. For example, in 4.4:=20 >> Otherwise, the values of Information Elements of float32 or = float64 >> types are represented as an optionally sign-prefixed, optionally >> base-10 exponent-suffixed, floating point decimal number. >>=20 >> -=20 >> If the Enclosing Context defines a representation for binary = objects, >> that representation should be used. >>=20 >> The should is weird. If it's a should, you should specify the = exception(s). >> Otherwise, it's a must.=20 >> Anyway, you had to make it clear when someone is compliant with this = spec. >> Btw, why do you always need this sentence in 4.x? >>=20 >>=20 >> -=20 >> I don't think it's appropriate to have [iana-ipfix-assignments] as a = normative reference. >> In RFC7011 and RFC7012, it is informative >>=20 >>=20 >> - If figure 2 is the IPFIX Message, it should follow the same format = as the RFC 7011 appendix examples. >> Then people will be able to compare.=20 >> =20 >> - change "Figure 2: IPFIX message containing sample flow" to "Figure = 2: IPFIX Message containing sample Flow Records >> change=20 >> "A Message containing this Template and a Data Record >> is shown in Figure 2" >> to=20 >> "An IPFIX Message containing this Template and a Data Record >> is shown in Figure 2" >>=20 >> - >> OLD: >> A Message containing this Template and a Data Record >> is shown in Figure 2, and a corresponding JSON Object using the = text >> format defined in this document is shown in Figure 3. >>=20 >> NEW: >>=20 >> An IPFIX Message containing this Template and a Data Record >> is shown in Figure 2, and a corresponding JSON Object using the = text >> format defined in this document is shown in Figure 3. >>=20 >>=20 >> Regards, Benoit >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPFIX mailing list >> 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=_317103DD-5F99-42E0-AC96-D885931A272A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 hi Benoit,

On 14 May 2014, at 19:03, Benoit Claise <bclaise@cisco.com> wrote:

Hi Brian,

Thanks for the new version 5 of the draft.

One small editorial point.
You correctly mention the references "XML [W3C-XML], JSON [RFC4627])" later in the text, but forgot the XML reference in the intro. See "JSON [RFC4627] or XML".

Oops, thanks for the catch.

Please correct that in your temp version.

Already done.

The draft is now sent to the IETF LC.

Thanks, cheers,

Brian


Regards, Benoit
Brian,

Below is my AD review
-
  However, present and future operations and management protocols and
   applications may use textual encodings, and generic framing and
   structure as in JSON or XML. 

Please add references

-
 A definition of canonical textual
   encodings for the IPFIX abstract data types would allow this set of
   Information Elements to be used for such applications, and for these
   applications to interoperate with IPFIX applications at the
   Information Element definition level.

   Note that templating or other mechanisms for data description for
   such applications and protocols are application specific, and
   therefore out of scope for this document: only Information Element
   identification and data value representation are defined here.

"such applications" don't refer to IPFIX applications from the previous paragraph

- 

Note that templating or other mechanisms for data description for
   such applications and protocols are application specific, and
   therefore out of scope for this document: only Information Element
   identification and data value representation are defined here.


and 


 Enclosing Context
      Textual representation of IPFIX data values is applied to use the
      IPFIX Information Model within some existing textual format (e.g.
      XML, JSON).  This outer format is referred to as the Enclosing
      Context within this document.  Enclosing Contexts define escaping
      and quoting rules for represented data values.

what is "data value"? It should be Information Element value

-  Leading zeroes are allowed in any either encoding, and do not signify
   base-8 (octal) encoding.  Binary encoding is intended for use with
   Information Elements with flag semantics, but can be used in any
   case.

I guess you mean the "binary representation of unsigned"


 - Why should and not must?
   Instead, applications using textual representations of Information
   Elements should use Information Element names to identify them; see
   Appendix A for examples illustrating this principle.


- btw, I found the RFC 2119 keywords in http://tools.ietf.org/id/draft-trammell-ipfix-text-adt-03.txt more appropriate, so that implementations could be compliant with this future RFC.
However, I could live with that. Let's see what the other ADs will say.

- 
Otherwise, the values of Information Elements of signed integer types
   should be represented as optionally-prefixed base-10 (decimal)
   strings.
should be -> must?
You are not consistent in the 4.X sections. For example, in 4.4: 
   Otherwise, the values of Information Elements of float32 or float64
   types are represented as an optionally sign-prefixed, optionally
   base-10 exponent-suffixed, floating point decimal number.


- 
   If the Enclosing Context defines a representation for binary objects,
   that representation should be used.

The should is weird. If it's a should, you should specify the exception(s).
Otherwise, it's a must. 
Anyway, you had to make it clear when someone is compliant with this spec.
Btw, why do you always need this sentence in 4.x?


- 
I don't think it's appropriate to have [iana-ipfix-assignments] as a normative reference.
In RFC7011 and RFC7012, it is informative


- If figure 2 is the IPFIX Message, it should follow the same format as the RFC 7011 appendix examples.
Then people will be able to compare. 
 
- change "Figure 2: IPFIX message containing sample flow" to "Figure 2: IPFIX Message containing sample Flow Records
change 
   "A Message containing this Template and a Data Record
   is shown in Figure 2"
to 
   "An IPFIX Message containing this Template and a Data Record
   is shown in Figure 2"

-
OLD:
   A Message containing this Template and a Data Record
   is shown in Figure 2, and a corresponding JSON Object using the text
   format defined in this document is shown in Figure 3.

NEW:

   An IPFIX Message containing this Template and a Data Record
   is shown in Figure 2, and a corresponding JSON Object using the text
   format defined in this document is shown in Figure 3.


Regards, Benoit





_______________________________________________
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

--Apple-Mail=_317103DD-5F99-42E0-AC96-D885931A272A-- --Apple-Mail=_EE43C08A-A8EF-4C91-A896-D89719EFF00F 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 iQEcBAEBCgAGBQJTdIvtAAoJENt3nsOmbNJcsEcH/A9tlGghxMYysfDPRjDH2gw7 vaiR5ErEMEjdchUNwHPFDw5x4iXMOdSCXBhZl6shH084bcSpwSx/JOCPEeEycBxi QDDqaNQIwQ17lkOCesuYV1XwHtmXO6FALRg1AKougLeCCdilkBXf+HpCMr7L8W7J pqA2yvmcf6w+FTmAtS1oZFwmm53Ez//qqkUqfnoa9UShz7PPbTyTnsSKpUrdgf+S EZm1HLHoppOd+1to9H9TbF4l+HBEIVJSk/XfoW2stRB2uOwfIXnSln+X8u32kDPs QcaXSzG9VroahEIdQmfFZHSDBBIIefLUHNCcADLaLkxKve66N7RLs2uyZ9LKbM0= =TH7v -----END PGP SIGNATURE----- --Apple-Mail=_EE43C08A-A8EF-4C91-A896-D89719EFF00F-- From nobody Wed May 21 18:30:12 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 493EC1A0031; Wed, 21 May 2014 18:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 HVcfiRMKIipC; Wed, 21 May 2014 18:30:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 867191A0029; Wed, 21 May 2014 18:30:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1A97518000D; Wed, 21 May 2014 18:29:51 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140522012951.1A97518000D@rfc-editor.org> Date: Wed, 21 May 2014 18:29:51 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/Gch6W8KfduG8PMi8W_jXJ00YRwo Cc: drafts-update-ref@iana.org, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 7133 on Information Elements for Data Link Layer Traffic Measurement 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, 22 May 2014 01:30:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7133 Title: Information Elements for Data Link Layer Traffic Measurement Author: S. Kashima, A. Kobayashi, Ed., P. Aitken Status: Standards Track Stream: IETF Date: May 2014 Mailbox: kashima@nttv6.net, akoba@nttv6.net, paitken@cisco.com Pages: 41 Characters: 76209 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-data-link-layer-monitoring-08.txt URL: http://www.rfc-editor.org/rfc/rfc7133.txt This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. This document is a product of the IP Flow Information Export Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun May 25 14:27: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 CB0381A02EA; Fri, 23 May 2014 19:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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_LOW=-0.7, 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 slcJBpKyA3BC; Fri, 23 May 2014 19:11:07 -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 5180B1A02E6; Fri, 23 May 2014 19:11:06 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4O2B2b2014998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2014 22:11:03 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s4O2B2b2014998 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1400897463; bh=4ussH1jHNv/ZXqvw6y5NjxLyGz4=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GMfZAoP9RwjJN8d8HM2Dhavi+fwY+g/Ew+M382QbJyh0tHx71OuxYg/PUUkRBTl+b a4AKaXB5LQuXaTC7qk3NkG+/eKEJ3cowVq1K98QHgKP3UFhvj8AWWNuiFaM43rlHOW 9XfmWS769nGAE+nMYk+QMhOCbW+8sZGTfQy3GxJY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s4O2B2b2014998 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 23 May 2014 19:10:48 -0700 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4O2AmFa017173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 May 2014 22:10:48 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Fri, 23 May 2014 22:10:48 -0400 From: "Black, David" To: "ietf@trammell.ch" , "General Area Review Team (gen-art@ietf.org)" Date: Fri, 23 May 2014 22:10:47 -0400 Thread-Topic: Gen-ART review of draft-ietf-ipfix-text-adt-05 Thread-Index: Ac929V7zhjIWDi0GQXixOzBRCQWkcQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C662F4B@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/M8IGWlbZnL2iAPQCTcPNl-Y-IYk X-Mailman-Approved-At: Sun, 25 May 2014 14:27:45 -0700 Cc: "Black, David" , "ietf@ietf.org" , "ipfix@ietf.org" Subject: [IPFIX] Gen-ART review of draft-ietf-ipfix-text-adt-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: Sat, 24 May 2014 02:11:17 -0000 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 =20 As Information Elements of the string type are simply UTF-8 encoded strings, they are represented directly, subject to the escaping and 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 mixed- 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 restrictions 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 is not obvious. I suggest "The dateTime Data Types" as a better section title. 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) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754=09 ---------------------------------------------------- From nobody Wed May 28 02:22: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 5789E1A03E3; Wed, 28 May 2014 02:22:11 -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 vTae7W3zK478; Wed, 28 May 2014 02:22:09 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 061971A0041; Wed, 28 May 2014 02:22:08 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::8] (unknown [IPv6:2001:67c:10ec:2a49:8000::8]) by trammell.ch (Postfix) with ESMTPSA id C04E81A0204; Wed, 28 May 2014 11:21:34 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F5757648-B88E-4692-9C70-BB3BABA38F85"; 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: <8D3D17ACE214DC429325B2B98F3AE712076C662F4B@MX15A.corp.emc.com> Date: Wed, 28 May 2014 11:21:35 +0200 Message-Id: <63FBCD8F-C028-4AE6-B3CF-F8FDFB98102B@trammell.ch> References: <8D3D17ACE214DC429325B2B98F3AE712076C662F4B@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/o-u6KLz9s_Rekfg8GcbHeS0yhlc Cc: "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" , "ipfix@ietf.org" Subject: Re: [IPFIX] Gen-ART review of draft-ietf-ipfix-text-adt-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: Wed, 28 May 2014 09:22:11 -0000 --Apple-Mail=_F5757648-B88E-4692-9C70-BB3BABA38F85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 hi David, Many thanks for the review. Comments and questions inline. On 24 May 2014, at 04:10, Black, David wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-ipfix-text-adt-05 > Reviewer: David L. Black > Review Date: May 23, 2014 > IETF LC End Date: May 28, 2014 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > This is a relatively short draft defining textual representations of > IPFIX data elements. It's clear and easy to read. >=20 > I assume that all the ABNF has been checked. Yep. > The open issues involve use of Unicode. This is unsurprising. :) > Minor issues: >=20 > Section 4.7 string =20 >=20 > As Information Elements of the string type are simply UTF-8 encoded > strings, they are represented directly, subject to the escaping and > encoding rules of the Enclosing Context. >=20 > There's nothing "simply" about use of UTF-8 encoded strings :-). Well, no. But most of the string normalization nightmares with UTF-8 are = also problems in the Enclosing Contexts as well, so the assumption here = is that if you're already representing strings in, say, UTF-8 encoded = JSON, you're already paying the UTF-8 tax, so this document presents no = additional considerations. There is an additional point here, though, that the Enclosing Context = may prefer or require a different encoding than UTF-8, so we should = address that: As Information Elements of the string type are simply Unicode=20 strings (encoded as UTF-8 when appearing in Data Sets in IPFIX=20= Messages [RFC 7011]), they are represented directly, using the=20= Unicode encoding rules and quoting and escaping rules of the=20 Enclosing Context. > 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. We largely presume these to be the responsibility of the Enclosing = Context (in this document) and the Metering Process that created the = string in the first place. Neither 7011 nor this representation present = additional considerations here: we just take the Unicode string we get = from whoever wants to send/store it and shovel it out. I'm not sure it makes sense to enforce normalization in this context. > 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. Generally, text-adt is intended to allow the use of the IPFIX = Information Model separately from the protocol described in RFC 7011, so = any concern there should also be raised here.=20 > 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. Good point; is there a good cite for this? > 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. >=20 > Section 4.1.5 of the pr=E9cis framework draft warns against use of = mixed- > 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. >=20 > Lots of mischief is possible with non-printing and control characters = - > I would expect that the Enclosing Context contains sufficient = restrictions > on use of Unicode to deal with most of this concern, and would state = that > expectation. This comment is definitely specific to this draft. >=20 > Nits/editorial comments: >=20 > Section 4.4 float32 and float64 >=20 > exponent =3D ( "e" / "E" ) [sign] 1*3DIGIT >=20 > Please explain why no more than 3 digits are ever required. Will do (i.e., because the maximum ranges on the type range from = O(1e-3xx) - O(1e3xx)).=20 > Section 4.8 dateTime* >=20 > The '*' in the section title, dateTime* is clever, but it's meaning is = not > obvious. I suggest "The dateTime Data Types" as a better section = title. Yep, thanks. > Section 5 Security Considerations >=20 > The security considerations for the IPFIX Protocol [RFC7011] apply; > this document presents no additional security considerations. >=20 > That's ok, although adding a direct mention of the [UTF8-EXPLOIT] TR > cited in RFC 7011 would be helpful. Will do. > 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. Oops; will replace. Thanks again, cheers, Brian --Apple-Mail=_F5757648-B88E-4692-9C70-BB3BABA38F85 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 iQEcBAEBCgAGBQJThaqfAAoJENt3nsOmbNJcE8wH/R+mvJGJq3AcEWkqU9yQxbU4 Wgf9VaEn2ptJ4kpQBi5XojAvJ15v6jG1xsKcc5E7AX3G/ZRTw4W5isDU0zyyNdTB aJIkBxtuv165tlyXFsw3x216wPOfSRzkKBAm1NqnyVxIs9YDek8wrH8glfpOFuQX 2VaLukARHiZ0KTxTLppOXewxWzXn4UmhyiXr3r4WYGO96LTRrXpJfQGXOvACACFl 8evXwebNzfoz1cr/60Qm6eTaJpuZi+sxJbxdawZdbksmJu0mOey69CgqTVwi9pkc 4I9Yz9gYI2+1i6ITXb+Fb+DewMW/VI7onPfS5hOjEW6TR4AOWCZ/Oh1Bs6eaWp0= =YQV4 -----END PGP SIGNATURE----- --Apple-Mail=_F5757648-B88E-4692-9C70-BB3BABA38F85-- From nobody Wed May 28 07:12:13 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 E253F1A0141 for ; Wed, 28 May 2014 07:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.17 X-Spam-Level: X-Spam-Status: No, score=-14.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, 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 wZgiyec72ihP for ; Wed, 28 May 2014 07:12:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9021A09B5 for ; Wed, 28 May 2014 07:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4852; q=dns/txt; s=iport; t=1401286311; x=1402495911; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1TPAW1Es+ng/cN0WxhkTZxKl64Og96GEXHIOwvgAmRQ=; b=NLJpu/1vF1BQRkJb7F7/JlO+B/vWAztk5lcFUYILL3SzH2oWhMs6ZJxK XbiudLtQZz2G7GFoDLgRRixrYpPfPsPluod8y3qsmnesZsojfO1s5RBID g9bTYR2cJRMODZ0dJNqoClLAM4FknDja//IFSrdL5/O+KoZbHRy+TFy1G Q=; X-IronPort-AV: E=Sophos;i="4.98,928,1392163200"; d="scan'208,217";a="328329984" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP; 28 May 2014 14:11:50 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4SEBodq020229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 14:11:50 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.188]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 28 May 2014 09:11:50 -0500 From: "Senthil Sivakumar (ssenthil)" To: "ipfix@ietf.org" Thread-Topic: NAT IPFIX logging draft Thread-Index: AQHPen7EGXeM/v5fmEOrLN7GgQHYWw== Date: Wed, 28 May 2014 14:11:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [64.102.83.140] Content-Type: multipart/alternative; boundary="_000_CFAB66991071C2ssenthilciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/RqxSGZcCTf_ZQlxLYkJ0FBdf9xo Cc: "spencerdawkins.ietf@gmail.com" Subject: [IPFIX] FW: NAT IPFIX logging draft 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, 28 May 2014 14:12:11 -0000 --_000_CFAB66991071C2ssenthilciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable During review of this draft http://tools.ietf.org/html/draft-ietf-behave-ip= fix-nat-logging-03, the following question was raised by Spencer SD: I noticed that some IEs below have a name that matches http://www.iana.= org/assignments/ipfix/ipfix.xhtml#ipfix-information-elements for the same I= PFIX ID number, but others do not ("timeStamp" here doesn't match "observat= ionTimeMilliseconds", but both are IPFIX ID 323, aren't they?) Is there a r= eason to use names that don't match the IANA registry? [Senthil] Good question, in case of timeStamp, I was looking for something = that already existed in the IPFIX registry rather than asking for a new one= . However, the terminology of "observationTimeMilliseconds" is not the term= inology that we use in the NAT drafts/rfc's. So I am open to suggestions he= re. I can clarify in the description that is called observationTimeMilliSec= onds". The other field is internalAddressRealm and externalAddresRealm, thi= s is the terminology that we used in NAT MIB, syslog and other documents. H= owever, when we defined the IPFIX IE, we didn=92t stick to the same termino= logy, so I don=92t know if I can go and ask the IPFIX IANA to change the na= me. Again I am open to suggestions, the dillema is whether I should stick t= o the existing IPFIX IANA terminology or the behave documents terminology. I was asked to take this discussion here on how best to resolve this, any s= uggestions are greatly appreciated! Thanks Senthil --_000_CFAB66991071C2ssenthilciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8C2A0D11873CE047ADE8C4A375D85B15@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


During r= eview of this draft http://tools.ietf.org/html/draft-ietf-behave-ip= fix-nat-logging-03, the following question was raised by Spencer
SD: I noticed that some IEs below have a n= ame that matches http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-i= nformation-elements for the same IPFIX ID number, but others do not ("timeStamp" here do= esn't match "observationTimeMilliseconds", but both are IPFIX ID = 323, aren't they?) Is there a reason to use names that don't match the IANA= registry?

[Senthil] Good question, in case of timeStamp, I was looking for somet= hing that already existed in the IPFIX registry rather than asking for a ne= w one. However, the terminology of "observationTimeMilliseconds" = is not the terminology that we use in the NAT drafts/rfc's. So I am open to suggestions here. I can clarify in the d= escription that is called observationTimeMilliSeconds". The other fiel= d is internalAddressRealm and externalAddresRealm, this is the terminology = that we used in NAT MIB, syslog and other documents. However, when we defined the IPFIX IE, we didn=92t stick to the= same terminology, so I don=92t know if I can go and ask the IPFIX IANA to = change the name. Again I am open to suggestions, the dillema is whether I s= hould stick to the existing IPFIX IANA terminology or the behave documents terminology.
I was asked to take this discussion here on how best to resolve this, = any suggestions are greatly appreciated! 

Thanks
Senthil
 --_000_CFAB66991071C2ssenthilciscocom_-- From nobody Wed May 28 15:03: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 B97D81A011F; Wed, 28 May 2014 06:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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_LOW=-0.7, 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 kLEwhtSQpRyl; Wed, 28 May 2014 06:58:59 -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 09BDD1A099F; Wed, 28 May 2014 06:58:58 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4SDwp2E008062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2014 09:58:54 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s4SDwp2E008062 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401285534; bh=eFAF+J9/ukjf8xyH/fBK2u+po6I=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=jjCNqlkfIt0VD1ygeed4VMbdW8106QeagwSrg+5snneNHmyb4l7OhjV39i37fFczm qfKfsGO1vfbV/K/dUJGrxqGTLEomLxAjojVJZo1tmz5nP7AtXJ+zh899cKcHatPv6A q62e4GjG3TASvdfhQySTqz5hNR9mx5lMzuDopJV0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s4SDwp2E008062 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 28 May 2014 09:58:40 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4SDwcn4014251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 09:58:39 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Wed, 28 May 2014 09:58:38 -0400 From: "Black, David" To: Brian Trammell Date: Wed, 28 May 2014 09:58:35 -0400 Thread-Topic: Gen-ART review of draft-ietf-ipfix-text-adt-05 Thread-Index: Ac96Vj0RglDvto1+Rc+Gf4hNIgGJhQAJJnDA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C6632B4@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C662F4B@MX15A.corp.emc.com> <63FBCD8F-C028-4AE6-B3CF-F8FDFB98102B@trammell.ch> In-Reply-To: <63FBCD8F-C028-4AE6-B3CF-F8FDFB98102B@trammell.ch> 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: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/Db1yZjJJf2W_IA-NorXbtfedBMg X-Mailman-Approved-At: Wed, 28 May 2014 15:03:17 -0700 Cc: "Black, David" , "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" , "ipfix@ietf.org" Subject: Re: [IPFIX] Gen-ART review of draft-ietf-ipfix-text-adt-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: Wed, 28 May 2014 13:59:02 -0000 Brian, Thanks for the response. Regarding Unicode string normalization and preparation, if those were appropriate, they should have been introduced in RFC 7011, and picked up here by reference. If there's an actual problem that requires those techniques (unclear), a revision to RFC 7011 would be the right place to address that problem, not this draft. I would note that the sheer volume of monitoring data tends to require automatic processing by recipients, and such tools are likely to compare strings in monitoring data.=20 I definitely agree that some text about Enclosing Context rules/requirement= s for Unicode usage would help, e.g., along the lines of: > We largely presume these to be the responsibility of the Enclosing Contex= t (in > this document) and the Metering Process that created the string in the fi= rst > place. Neither 7011 nor this representation present additional considerat= ions > here: we just take the Unicode string we get from whoever wants to send/s= tore > it and shovel it out. and > > Lots of mischief is possible with non-printing and control characters - > > I would expect that the Enclosing Context contains sufficient restricti= ons > > on use of Unicode to deal with most of this concern, and would state th= at > > expectation. This comment is definitely specific to this draft. So, please do add some text on this topic. > > 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. >=20 > Good point; is there a good cite for this? Try RFC 6885 - Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS) > > Section 4.1.5 of the pr=E9cis framework draft warns against use of mixe= d- > > direction Unicode strings, as "there is currently no widely accepted an= d > > implemented solution for the processing and safe display of mixed- > > direction strings." That warning deserves repetition here. Please repeat that warning, probably w/an informative reference to the pr=E9cis framework draft. Thanks, --David > -----Original Message----- > From: Brian Trammell [mailto:ietf@trammell.ch] > Sent: Wednesday, May 28, 2014 5:22 AM > To: Black, David > Cc: General Area Review Team (gen-art@ietf.org); ipfix@ietf.org; ietf@iet= f.org > Subject: Re: Gen-ART review of draft-ietf-ipfix-text-adt-05 >=20 > hi David, >=20 > Many thanks for the review. Comments and questions inline. >=20 > On 24 May 2014, at 04:10, Black, David wrote: >=20 > > 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. >=20 > Yep. >=20 > > The open issues involve use of Unicode. >=20 > This is unsurprising. :) >=20 > > Minor issues: > > > > Section 4.7 string > > > > As Information Elements of the string type are simply UTF-8 encoded > > strings, they are represented directly, subject to the escaping and > > encoding rules of the Enclosing Context. > > > > There's nothing "simply" about use of UTF-8 encoded strings :-). >=20 > Well, no. But most of the string normalization nightmares with UTF-8 are = also > problems in the Enclosing Contexts as well, so the assumption here is tha= t if > you're already representing strings in, say, UTF-8 encoded JSON, you're > already paying the UTF-8 tax, so this document presents no additional > considerations. >=20 > There is an additional point here, though, that the Enclosing Context may > prefer or require a different encoding than UTF-8, so we should address t= hat: >=20 > As Information Elements of the string type are simply Unicode > strings (encoded as UTF-8 when appearing in Data Sets in IPFIX > Messages [RFC 7011]), they are represented directly, using the > Unicode encoding rules and quoting and escaping rules of the > Enclosing Context. >=20 > > There appear to be no restrictions on Unicode codepoint usage and no > > requirements for string normalization or other preparation either in th= is > > draft or RFC 7011. >=20 > We largely presume these to be the responsibility of the Enclosing Contex= t (in > this document) and the Metering Process that created the string in the fi= rst > place. Neither 7011 nor this representation present additional considerat= ions > here: we just take the Unicode string we get from whoever wants to send/s= tore > it and shovel it out. >=20 > I'm not sure it makes sense to enforce normalization in this context. >=20 > > 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. >=20 > Generally, text-adt is intended to allow the use of the IPFIX Information > Model separately from the protocol described in RFC 7011, so any concern = there > should also be raised here. >=20 > > 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. >=20 > Good point; is there a good cite for this? >=20 > > 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 mixe= d- > > direction Unicode strings, as "there is currently no widely accepted an= d > > 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 restricti= ons > > on use of Unicode to deal with most of this concern, and would state th= at > > 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. >=20 > Will do (i.e., because the maximum ranges on the type range from O(1e-3xx= ) - > O(1e3xx)). >=20 > > Section 4.8 dateTime* > > > > The '*' in the section title, dateTime* is clever, but it's meaning is = not > > obvious. I suggest "The dateTime Data Types" as a better section title= . >=20 > Yep, thanks. >=20 > > 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. >=20 > Will do. >=20 > > idnits 2.13.01 warns that the JSON reference (RFC 4627) is obsolete, an= d > > needs to be replaced with one or two current RFC references. >=20 > Oops; will replace. >=20 > Thanks again, cheers, >=20 > Brian