From nobody Mon Jun 2 02:42: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 BC9DD1A02EB for ; Mon, 2 Jun 2014 02:42:44 -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 dWGhnBHO2xCQ for ; Mon, 2 Jun 2014 02:42:43 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id BC0801A02EA for ; Mon, 2 Jun 2014 02:42:42 -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 A244B1A02DC; Mon, 2 Jun 2014 11:42:06 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_17261C50-DCE7-468A-BA98-13D3CE670AE0"; 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: Date: Mon, 2 Jun 2014 11:42:08 +0200 Message-Id: <9D87B607-2C83-4F08-AB72-557AFEB95127@trammell.ch> References: To: "Senthil Sivakumar (ssenthil)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/2M4387DCnBKZY6hTdq1JfwTnDJY Cc: "spencerdawkins.ietf@gmail.com" , "ipfix@ietf.org" Subject: Re: [IPFIX] 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: Mon, 02 Jun 2014 09:42:44 -0000 --Apple-Mail=_17261C50-DCE7-468A-BA98-13D3CE670AE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Senthil, First, please read RFC 7013 if you have not done so already, and ensure = that all IE definitions in this draft comply to the requirements = therein. Specifically, the descriptions in Section 5.2 are unimplementably brief. = You don't need to give full definitions for IEs you're reusing, but you = do need to fully define new IEs you want to create. More points inline. On 28 May 2014, at 16:11, Senthil Sivakumar (ssenthil) = wrote: >=20 >=20 > During review of this draft = http://tools.ietf.org/html/draft-ietf-behave-ipfix-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-elemen= ts for the same IPFIX ID number, but others do not ("timeStamp" here = doesn'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? Not only is there no reason to use names that don't match the IANA = registry, we do not consider giving different names to codepoints in the = IANA registry to be valid at all in any context. >> [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 terminology that we use in the NAT drafts/rfc's. So I am open = to suggestions here. I can clarify in the description that is called = observationTimeMilliSeconds". Note that an "observation" is "when the MP noticed an event", which for = MPs colocated with packet-treatment devices is synonomous with "event = time". So "observationTimeMilliseconds" is what you want if you want to = limit implementors to millisecond-level precision. I would strongly suggest creating a Terminology section that maps Behave = terminology to IPFIX terminology. >> The other field 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. You can certainly ask, though I suspect that a request to change IE = 229's name to "internalAddressRealm" would be denied by the IE-DOCTORS = as it is not clearly specific to NAT applications. It's also not at all = clear to me that 229 refers to something that could be called = "internalAddressRealm" -- natOriginatingAddressRealm per its definition = refers to the side of the address realm boundary from which the first = packet came. =46rom a data modeling standpoint, it is not at all clear to me why you = want to (1) report "internalAddressRealm" and "externalAddressRealm" = separately and (2) why you want to report this as opposed to = natOriginatingAddressRealm as defined. This is not a full review of the document; one will hopefully follow but = I'm somewhat overcommitted at the moment. Regards, Brian >> Again I am open to suggestions, the dillema is whether I should 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!=20 >=20 > Thanks > Senthil > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_17261C50-DCE7-468A-BA98-13D3CE670AE0 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 iQEcBAEBCgAGBQJTjEbwAAoJENt3nsOmbNJccnAIAJLLRhKA7r17OxuhgedEyDU5 3BoXD2Aa2mDNvxpnSzF+edVuGHxTJXAXHhgdYLZ7ePO4SKOI3QEVRDR8QC1Sfxdh vUF8aRr23GPqDU3LRb5YNRsoaq1r8sgPTELTt0nIt6x6qA0bD4/UZSDDfzmm7LJp PZXg8V7a+nXeQkdd+UgLwOjMBpR6Vam0o3Ukk7lDtOTIR3fcG/gDSZGAqomcLSVq CqZkxFQEwisuE2xOaLg2mSBhQjAYLI/AX/E0CzOvN1n16n0/KxmOFVDPGWz2MKOA bc23D4NhrIN6J/Cnx5sOoVJCYZb962s6PLDSbKgcKe4clW3CVAYDEWkKYUQsizs= =cOJ1 -----END PGP SIGNATURE----- --Apple-Mail=_17261C50-DCE7-468A-BA98-13D3CE670AE0-- From nobody Mon Jun 2 08:46: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 965551A036B for ; Mon, 2 Jun 2014 08:46:51 -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 EnN4HpOOR3Vx for ; Mon, 2 Jun 2014 08:46:49 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33071A0141 for ; Mon, 2 Jun 2014 08:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4106; q=dns/txt; s=iport; t=1401724004; x=1402933604; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WSqeQBTejtCoXCUUOUiVZbjXmCodFRnVHhEvXiYFm6s=; b=DqZxog9uVX857psYHVzovdfTOsL2mUpR1Mpw99f8bRAKFNnJf+hp1r7b /j7jDQBCPF+AzNCMfNm3Kn1zobBkSJgcEqMHkXRjH4UkOgweIgKfc9EvK 29Oare/rNzoka9NSjueVh4bRqotMtf4yYGNBRcsiG7YoHAM+OtlqGa2qY w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIabjFOtJV2U/2dsb2JhbABYgwdSWLsdhzkBgRQWdIIlAQEBBAEBAWsLEAIBCA4KLicLJQIEDgUJiDkN0y8XjXtXB4RABIlrkBWBPpFvgzhsgQJB X-IronPort-AV: E=Sophos;i="4.98,957,1392163200"; d="scan'208";a="49410665" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 02 Jun 2014 15:46:43 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s52Fkhbc020201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 15:46:43 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.249]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 2 Jun 2014 10:46:43 -0500 From: "Senthil Sivakumar (ssenthil)" To: Brian Trammell Thread-Topic: [IPFIX] NAT IPFIX logging draft Thread-Index: AQHPen7EGXeM/v5fmEOrLN7GgQHYW5td7KsAgAAiywA= Date: Mon, 2 Jun 2014 15:46:42 +0000 Message-ID: References: <9D87B607-2C83-4F08-AB72-557AFEB95127@trammell.ch> In-Reply-To: <9D87B607-2C83-4F08-AB72-557AFEB95127@trammell.ch> 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: text/plain; charset="iso-8859-1" Content-ID: <2F3B4C53BBCD3F42BB0D5E465E664114@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/uqQXWUdejqaOx-MR1lUEO4HyOnE Cc: "spencerdawkins.ietf@gmail.com" , "ipfix@ietf.org" Subject: Re: [IPFIX] 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: Mon, 02 Jun 2014 15:46:51 -0000 Hi Brian, Please see inline. On 6/2/14 5:42 AM, "Brian Trammell" wrote: >Hi, Senthil, > >First, please read RFC 7013 if you have not done so already, and ensure >that all IE definitions in this draft comply to the requirements therein. > >Specifically, the descriptions in Section 5.2 are unimplementably brief. >You don't need to give full definitions for IEs you're reusing, but you >do need to fully define new IEs you want to create. Ok, as you could see in that table 5.2 most of the IE's are already defined in IPFIX registry, but for the ones that are not, I will make them verbose, in the IANA considerations section. > >More points inline. > >On 28 May 2014, at 16:11, Senthil Sivakumar (ssenthil) > wrote: > >>=20 >>=20 >> During review of this draft >>http://tools.ietf.org/html/draft-ietf-behave-ipfix-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-elem >>>ents for the same IPFIX ID number, but others do not ("timeStamp" here >>>doesn'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? > >Not only is there no reason to use names that don't match the IANA >registry, we do not consider giving different names to codepoints in the >IANA registry to be valid at all in any context. > >>> [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 terminology that we use in the >>>NAT drafts/rfc's. So I am open to suggestions here. I can clarify in >>>the description that is called observationTimeMilliSeconds". > >Note that an "observation" is "when the MP noticed an event", which for >MPs colocated with packet-treatment devices is synonomous with "event >time". So "observationTimeMilliseconds" is what you want if you want to >limit implementors to millisecond-level precision. > >I would strongly suggest creating a Terminology section that maps Behave >terminology to IPFIX terminology. Yep, agree, that would be the most practical way to address the terminology differences. > >>> The other field 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=B9t stick to the same >>>terminology, so I don=B9t know if I can go and ask the IPFIX IANA to >>>change the name. > >You can certainly ask, though I suspect that a request to change IE 229's >name to "internalAddressRealm" would be denied by the IE-DOCTORS as it is >not clearly specific to NAT applications. It's also not at all clear to >me that 229 refers to something that could be called >"internalAddressRealm" -- natOriginatingAddressRealm per its definition >refers to the side of the address realm boundary from which the first >packet came. > >From a data modeling standpoint, it is not at all clear to me why you >want to (1) report "internalAddressRealm" and "externalAddressRealm" >separately and (2) why you want to report this as opposed to >natOriginatingAddressRealm as defined. > >This is not a full review of the document; one will hopefully follow but >I'm somewhat overcommitted at the moment. Thanks, looking forward to your review comments. Senthil > >Regards, > >Brian > >>> Again I am open to suggestions, the dillema is whether I should 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! >>=20 >> Thanks >> Senthil >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > From nobody Wed Jun 4 08:49: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 9A55C1A0270 for ; Wed, 4 Jun 2014 08:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 hL5Zuqd0Bd0q for ; Wed, 4 Jun 2014 08:49:22 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E1D1A0227 for ; Wed, 4 Jun 2014 08:49:21 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i7so8022845oag.37 for ; Wed, 04 Jun 2014 08:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VCleVDmamJHFgDetXSFxXTgajXY/s/XBsbreer8M5aw=; b=MveC4sL7IOoktXQgg5Bt53539thOOEnP4C+xR3kgw0M9CJIDVtkeJMRDsKAG3Go4Uw PkjX7BNotfG8ss/rKLi0CSrJzdqHg2KI++Zx/rzYLtAkWtWqU1r+6uyps2PYqmiZdzHO /Kj/EC0qaPnWQReBSiiSE+R0ijJVpkOf+G5vI9CRtMcV/z87y/PFdTkGbUls627Xd8Nv JjQgwyzenc+pCqvqIRN3ZOo3NNBRZKsDbPLPU7hC0KdFZR2Lh8ciKZlv6oRvxrPQPQUd dEbghDwvs+hZ/wxCMXbiPYtSmn1+prnQ/EHp78k1n6Gwuxd+GGIwKBNUVyDdAoGv6/ao Y74g== X-Received: by 10.182.250.196 with SMTP id ze4mr52048771obc.46.1401896955654; Wed, 04 Jun 2014 08:49:15 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id gp4sm5429141obb.17.2014.06.04.08.49.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 08:49:15 -0700 (PDT) Message-ID: <538F3FF9.2060303@gmail.com> Date: Wed, 04 Jun 2014 10:49:13 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , Brian Trammell References: <9D87B607-2C83-4F08-AB72-557AFEB95127@trammell.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/RqFBKOe0Ly28EYXxylxL2ErA7tk Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] 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, 04 Jun 2014 15:49:23 -0000 On 06/02/2014 10:46 AM, Senthil Sivakumar (ssenthil) wrote: > Hi Brian, > Please see inline. Thank you, Brian, for your help. And thanks for being over-committed because you're doing OTHER TSV stuff, too :-) Spencer > On 6/2/14 5:42 AM, "Brian Trammell" wrote: > >> Hi, Senthil, >> >> First, please read RFC 7013 if you have not done so already, and ensure >> that all IE definitions in this draft comply to the requirements therein. >> >> Specifically, the descriptions in Section 5.2 are unimplementably brief. >> You don't need to give full definitions for IEs you're reusing, but you >> do need to fully define new IEs you want to create. > Ok, as you could see in that table 5.2 most of the IE's are already > defined in IPFIX registry, but for the ones that are not, I will make them > verbose, in the IANA considerations section. > >> More points inline. >> >> On 28 May 2014, at 16:11, Senthil Sivakumar (ssenthil) >> wrote: >> >>> >>> During review of this draft >>> http://tools.ietf.org/html/draft-ietf-behave-ipfix-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-elem >>>> ents for the same IPFIX ID number, but others do not ("timeStamp" here >>>> doesn'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? >> Not only is there no reason to use names that don't match the IANA >> registry, we do not consider giving different names to codepoints in the >> IANA registry to be valid at all in any context. >> >>>> [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 terminology that we use in the >>>> NAT drafts/rfc's. So I am open to suggestions here. I can clarify in >>>> the description that is called observationTimeMilliSeconds". >> Note that an "observation" is "when the MP noticed an event", which for >> MPs colocated with packet-treatment devices is synonomous with "event >> time". So "observationTimeMilliseconds" is what you want if you want to >> limit implementors to millisecond-level precision. >> >> I would strongly suggest creating a Terminology section that maps Behave >> terminology to IPFIX terminology. > Yep, agree, that would be the most practical way to address the > terminology differences. > >>>> The other field 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št stick to the same >>>> terminology, so I donšt know if I can go and ask the IPFIX IANA to >>>> change the name. >> You can certainly ask, though I suspect that a request to change IE 229's >> name to "internalAddressRealm" would be denied by the IE-DOCTORS as it is >> not clearly specific to NAT applications. It's also not at all clear to >> me that 229 refers to something that could be called >> "internalAddressRealm" -- natOriginatingAddressRealm per its definition >> refers to the side of the address realm boundary from which the first >> packet came. >> > >From a data modeling standpoint, it is not at all clear to me why you >> want to (1) report "internalAddressRealm" and "externalAddressRealm" >> separately and (2) why you want to report this as opposed to >> natOriginatingAddressRealm as defined. >> >> This is not a full review of the document; one will hopefully follow but >> I'm somewhat overcommitted at the moment. > Thanks, looking forward to your review comments. > > Senthil > >> Regards, >> >> Brian >> >>>> Again I am open to suggestions, the dillema is whether I should 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 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix From nobody Mon Jun 16 02:56:27 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 A53761B2A87; Mon, 16 Jun 2014 02:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 yll72t8qtW5X; Mon, 16 Jun 2014 02:56:19 -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 7C4A01B29B5; Mon, 16 Jun 2014 02:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8256; q=dns/txt; s=iport; t=1402912579; x=1404122179; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rdFhC5nvJi8t6OU+4vNkZfwBA8aozrqE1IjwOrlWLfg=; b=jyman3SpVB/Ni5+ckhrR8qQLvKjjUHfavf9gFLAeZKb36+/a3o/S/R1s FnEAGk0tyva2ffW9WvaMCldTMHbcDD6gB4dORPuI80PlOknl6aI7HdAvY mkHvmepP73YqQrSxN2u1NUisoKtg5N7rMESACMT1Mkg8fb3g/N4P4fdz0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAMC+nlOtJssW/2dsb2JhbABag1+qNgwBAQEBAQEFAZkkAYEodYQDAQEBBDIBBUABDAQLEQMBAQEBCRYIBwkDAgECATQJCAYBDAEFAgEBF4gnDc8IF4VjhxaBJVgHBoQ9AQOWNIQPgUOFN4xeg0I7L4EC X-IronPort-AV: E=Sophos;i="5.01,485,1400025600"; d="scan'208";a="83348231" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 16 Jun 2014 09:56:16 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5G9uG8L023862; Mon, 16 Jun 2014 09:56:16 GMT Message-ID: <539EBF3F.4060906@cisco.com> Date: Mon, 16 Jun 2014 11:56:15 +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: "Black, David" , Brian Trammell References: <8D3D17ACE214DC429325B2B98F3AE712076C662F4B@MX15A.corp.emc.com> <63FBCD8F-C028-4AE6-B3CF-F8FDFB98102B@trammell.ch> <8D3D17ACE214DC429325B2B98F3AE712076C6632B4@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C6632B4@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/ohsFhPmRr8wo8gYHE-9f_03xBSA 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: Mon, 16 Jun 2014 09:56:21 -0000 Hi Brian, Juergen, Do I understand correctly that you plan on submitting a new draft version to address David's feedback? Juergen, As far as I know, this is the only feedback received during IETF LC. If that's correct, when this feedback is addressed, I'll put this document on the IESG telechat. Regards, Benoit > 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. > > I definitely agree that some text about Enclosing Context rules/requirements > for Unicode usage would help, e.g., along the lines of: > >> 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. > and > >>> 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. > 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. >> 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écis 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. > Please repeat that warning, probably w/an informative reference to the > précis 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@ietf.org >> Subject: Re: Gen-ART review of draft-ietf-ipfix-text-adt-05 >> >> 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 >>> >>> . >>> >>> 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. >> Yep. >> >>> The open issues involve use of Unicode. >> This is unsurprising. :) >> >>> 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 :-). >> 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 >> 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. >> >>> 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. >> >>> 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écis framework draft >>> (draft-ietf-précis-framework) apply; a short summary and pointer >>> to that section of that draft should suffice. >>> >>> Section 4.1.5 of the précis 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 = ( "e" / "E" ) [sign] 1*3DIGIT >>> >>> 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)). >> >>> 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. >> Yep, thanks. >> >>> 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. >> 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 > . > From nobody Mon Jun 23 00:57:00 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 D86221B29E7; Mon, 23 Jun 2014 00:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ccUqAhD8rv74; Mon, 23 Jun 2014 00:56:50 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9141B287E; Mon, 23 Jun 2014 00:56:50 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 4ADFB1A13F1; Mon, 23 Jun 2014 09:56:48 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_72FCE113-833C-4C01-AEC7-92B2C80B1A83"; 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: <539EBF3F.4060906@cisco.com> Date: Mon, 23 Jun 2014 09:56:49 +0200 Message-Id: <9C4A391D-163B-48AB-9884-9FF311EDE026@trammell.ch> References: <8D3D17ACE214DC429325B2B98F3AE712076C662F4B@MX15A.corp.emc.com> <63FBCD8F-C028-4AE6-B3CF-F8FDFB98102B@trammell.ch> <8D3D17ACE214DC429325B2B98F3AE712076C6632B4@MX15A.corp.emc.com> <539EBF3F.4060906@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/q9c4fZEdiG3H_K4ykBbGuBri_V4 Cc: "Black, David" , "General Area Review Team \(gen-art@ietf.org\)" , "ipfix@ietf.org" , "ietf@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: Mon, 23 Jun 2014 07:56:54 -0000 --Apple-Mail=_72FCE113-833C-4C01-AEC7-92B2C80B1A83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 hi Benoit, Yep, that's my plan. Just back from vacation but should be able to = finally get to this this week. Cheers, Brian On 16 Jun 2014, at 11:56, Benoit Claise wrote: > Hi Brian, Juergen, >=20 > Do I understand correctly that you plan on submitting a new draft = version to address David's feedback? >=20 > Juergen, > As far as I know, this is the only feedback received during IETF LC. > If that's correct, when this feedback is addressed, I'll put this = document on the IESG telechat. >=20 > Regards, Benoit >> Brian, >>=20 >> Thanks for the response. >>=20 >> 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. >>=20 >> 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/requirements >> for Unicode usage would help, e.g., along the lines of: >>=20 >>> 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. >> and >>=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. >> So, please do add some text on this topic. >>=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? >> Try RFC 6885 - Stringprep Revision and Problem Statement >> for the Preparation and Comparison of Internationalized Strings = (PRECIS) >>=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. >> Please repeat that warning, probably w/an informative reference to = the >> pr=E9cis framework draft. >>=20 >> Thanks, >> --David >>=20 >>> -----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@ietf.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 >>>>=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. >>>=20 >>>> The open issues involve use of Unicode. >>> This is unsurprising. :) >>>=20 >>>> Minor issues: >>>>=20 >>>> 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. >>>>=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. >>>=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 that: >>>=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 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. >>>=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. >>> 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? >>>=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. >>>>=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. >>>=20 >>>> 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. >>>=20 >>>> 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. >>>=20 >>> Thanks again, cheers, >>>=20 >>> Brian >> . >>=20 >=20 --Apple-Mail=_72FCE113-833C-4C01-AEC7-92B2C80B1A83 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 iQEcBAEBCgAGBQJTp93BAAoJENt3nsOmbNJcgjgH/2nv6gf4stg3bCaJCaSmhbyS b4iSpDmIlig0gnSKuGmh4H0JbWzkulpKvki9U8wViUojWdRG6y/3/5+c+0b3ss/m G5HW5n8Lh1aFkjXeOGpLpE/cDsXvp85PcOu+tGxtRlrnvn5gShwhnNtOwGrfxDcw c/IAgYhRRW/TqEZbwR0cuarVbzJ63cxrihdYRFbrkKJnCVOuGNSu5rlhaB+z6Sqd WCTjG1aLSph9w2q1a9hRl7fZYlF5N7w07eV2eBMsMSI50WLobmfuZeaMJXPLvx2g uO3kbVb1xfjlhKxRlq69ygxk3xQcrzlV2Omz8ERDOnXuSDDdGNcCHlhkwijxZdA= =UmcN -----END PGP SIGNATURE----- --Apple-Mail=_72FCE113-833C-4C01-AEC7-92B2C80B1A83-- From nobody Tue Jun 24 08:20:50 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 F0BD21B2DC9; Tue, 24 Jun 2014 08:20:42 -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 9712bxzr7O92; Tue, 24 Jun 2014 08:20:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4C01B2D6A; Tue, 24 Jun 2014 08:18:44 -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.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624151844.4769.28603.idtracker@ietfa.amsl.com> Date: Tue, 24 Jun 2014 08:18:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/9YMdy3Rnwu3hXFnyQVW1AThWlas Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-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: Tue, 24 Jun 2014 15:20:43 -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-06.txt Pages : 12 Date : 2014-06-24 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-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 Tue Jun 24 12:45: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 742741A0391; Tue, 24 Jun 2014 12:45:27 -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 LqSZlFR4YmW2; Tue, 24 Jun 2014 12:45:25 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 45CA61A0387; Tue, 24 Jun 2014 12:45:25 -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 572A41A02D9; Tue, 24 Jun 2014 21:44:54 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F4F53B3A-5C89-4ACA-A92D-4424A1B2358B"; 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: <20140624151844.4769.28603.idtracker@ietfa.amsl.com> Date: Tue, 24 Jun 2014 21:44:53 +0200 Message-Id: References: <20140624151844.4769.28603.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/XI-3T9lGr5K2Wt-Bh1LyKvzbaH0 Cc: ipfix@ietf.org, i-d-announce@ietf.org Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-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: Tue, 24 Jun 2014 19:45:28 -0000 --Apple-Mail=_F4F53B3A-5C89-4ACA-A92D-4424A1B2358B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, This revision addresses GEN-ART review comments, and is IMO ready for = write up and publication. Best regards, Brian On 24 Jun 2014, at 17:18, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Textual Representation of IPFIX Abstract Data = Types > Author : Brian Trammell > Filename : draft-ietf-ipfix-text-adt-06.txt > Pages : 12 > Date : 2014-06-24 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-text-adt-06 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_F4F53B3A-5C89-4ACA-A92D-4424A1B2358B 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 iQEcBAEBCgAGBQJTqdU1AAoJENt3nsOmbNJcgHwH/3n3ab95jJaJEOoR48x0AFE/ 2HG5red4h/uhXhHMUHIcnvoZbsNEoxKMrbz9kzz14lJHgyafLBfZn2hCiL7BzBdO 0nXAnjHTJqhamt7tnrLjzdV2o0jIAhmyfzoyM4ykfyj2nAZp+sBPaElRm8ykJGML r5WjFHIQwQl+aySZ8nyBZhV3sbHaFnAr88rLy5Y605b/QqC23u09w8okcILzJN+S EBQ/yFWy8BfYALDBMd3m3CywotZWWymIhD5vPlSo4xpq7Eo2HckWq+XOyWgtTDn6 JSvdg2GlRDu+PopWiVjtWiUZJpjDRy/NsTXGVzTeU+RAlJBYmSFF0MRaOmdnXNA= =P6TC -----END PGP SIGNATURE----- --Apple-Mail=_F4F53B3A-5C89-4ACA-A92D-4424A1B2358B-- From nobody Tue Jun 24 14:30:03 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 677421B2823; Tue, 24 Jun 2014 14:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 JSxG5zYwWow9; Tue, 24 Jun 2014 14:23:25 -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 67E8A1B28AC; Tue, 24 Jun 2014 14:14:35 -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 s5OLEYFf029926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2014 17:14:34 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5OLEYFf029926 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1403644474; bh=Ppwy6ashI5Jrm5Nj/bzDEyLmplo=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ED85yU5C1GJ0AOME65AyDnz6S66VqMli7LX3OMwSgOVRalb0wjHulSnUADzSSPcGW 2hQdHxizHZN0wyFEMZWfe6yHXnYJDH3TdVAui7iX/fyMV4Bt1vBqg1PjjKaSj29hUh Ykdr/hrKH3kqD57aTC88uEcnewX7BWplOINqt9Fc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5OLEYFf029926 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Tue, 24 Jun 2014 17:14:16 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5OLEFlq006000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jun 2014 17:14:16 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Tue, 24 Jun 2014 17:14:15 -0400 From: "Black, David" To: "ietf@trammell.ch" , "General Area Review Team (gen-art@ietf.org)" Date: Tue, 24 Jun 2014 17:14:14 -0400 Thread-Topic: Gen-ART review of draft-ietf-ipfix-text-adt-05 Thread-Index: Ac929V7zhjIWDi0GQXixOzBRCQWkcQY+uSkA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077005024C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C662F4B@MX15A.corp.emc.com> In-Reply-To: <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: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public, Resumes Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/UVAd0Oq9wmNvf9t477bO8cWIpuA X-Mailman-Approved-At: Tue, 24 Jun 2014 14:30:00 -0700 Cc: "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: Tue, 24 Jun 2014 21:23:28 -0000 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 >=20 > 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. The open issues involve > use of Unicode. >=20 > Minor issues: >=20 > 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. >=20 > There's nothing "simply" about use of UTF-8 encoded strings :-). >=20 > 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. >=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. 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 restriction= s > 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. >=20 > Section 4.8 dateTime* >=20 > The '*' in the section title, dateTime* is clever, but it's meaning is no= t > obvious. I suggest "The dateTime Data Types" as a better section title. >=20 > 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. >=20 > 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. >=20 > 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-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From nobody Tue Jun 24 14:42:47 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 496B81B2893; Tue, 24 Jun 2014 14:41:39 -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 uryY-o9SGqUi; Tue, 24 Jun 2014 14:41:37 -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 F365A1A039C; Tue, 24 Jun 2014 14:41:36 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5OLfXLs025887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2014 17:41:34 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s5OLfXLs025887 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1403646094; bh=zGeTiLfSfkdI9CR4/kXbAaJQ5bM=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=PE5fmMuxLLDSs6HisbMQWXIsZ0ldK87G1LKSM/dpicSdHEWbpN79OjVenZWGCv6WT +KAjHndBSBODYjNRNjmtOaoqzNaq+pSGD1rCGw6JX6yOl25VQ9VbOgc3Lq/HMITKlG eyRM8tOYyZDgkT6/0ZQpZauKITHIf60eUqpMsiV8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s5OLfXLs025887 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Tue, 24 Jun 2014 17:41:26 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5OLfP9m029162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jun 2014 17:41:26 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Tue, 24 Jun 2014 17:41:26 -0400 From: "Black, David" To: "Black, David" , "ietf@trammell.ch" , "General Area Review Team (gen-art@ietf.org)" Date: Tue, 24 Jun 2014 17:41:24 -0400 Thread-Topic: Gen-ART review of draft-ietf-ipfix-text-adt-06 Thread-Index: Ac+P9QvTQoRjqJt7QiGkc8Ukj7DjIQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120770050255@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/EcaE1vBUUU-8AWyTUqHGYfUTm5U X-Mailman-Approved-At: Tue, 24 Jun 2014 14:42:45 -0700 Cc: "ietf@ietf.org" , "ipfix@ietf.org" Subject: [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, 24 Jun 2014 21:41:39 -0000 With correct subject line this time ... > -----Original Message----- > From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Black, David > 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 >=20 > The -06 version of this draft addresses all of the comments in the > Gen-ART review of the -05 version. >=20 > 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): >=20 > 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. >=20 > Thanks, > --David >=20 > > -----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 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 th= is > > 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 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. > > > > 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, an= d > > 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= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jun 24 23:16: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 B463F1B2AE0; Tue, 24 Jun 2014 23:16:14 -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 B6zd8du6snQV; Tue, 24 Jun 2014 23:16:12 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id F18BB1B2ADB; Tue, 24 Jun 2014 23:16:11 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::2] (unknown [IPv6:2001:470:26:9c2::2]) by trammell.ch (Postfix) with ESMTPSA id E81451A0158; Wed, 25 Jun 2014 08:16:09 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_6838806A-2549-465C-93C7-F7B14A15758C"; 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: <8D3D17ACE214DC429325B2B98F3AE7120770050255@MX15A.corp.emc.com> Date: Wed, 25 Jun 2014 08:16:09 +0200 Message-Id: <5D72BEB3-1038-48EE-AD8C-2BABD53B85B9@trammell.ch> References: <8D3D17ACE214DC429325B2B98F3AE7120770050255@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/BDZgRPFmdrQd1autDGa4j06yMxo 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-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: Wed, 25 Jun 2014 06:16:14 -0000 --Apple-Mail=_6838806A-2549-465C-93C7-F7B14A15758C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 hi David, On 24 Jun 2014, at 23:41, Black, David wrote: > With correct subject line this time ... >=20 >> -----Original Message----- >> From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Black, = David >> 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 >>=20 >> The -06 version of this draft addresses all of the comments in the >> Gen-ART review of the -05 version. >>=20 >> 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): >>=20 >> 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. Yep, that's better. I'll hold this for a -07 post-next-review-round. Many thanks, best regards, Brian >> Thanks, >> --David >>=20 >>> -----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 >>>=20 >>> 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. The open issues = involve >>> use of Unicode. >>>=20 >>> Minor issues: >>>=20 >>> 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. >>>=20 >>> There's nothing "simply" about use of UTF-8 encoded strings :-). >>>=20 >>> 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. >>>=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. 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. >>>=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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Distinguished Engineer >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> david.black@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>>=20 >>=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_6838806A-2549-465C-93C7-F7B14A15758C 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 iQEcBAEBCgAGBQJTqmkpAAoJENt3nsOmbNJc4ccH/j/NSZnKacb3CnA+KmcWyvJr cU1WQz0PCHMPY5vl8RRhMxrSVgyHK90f79+WkrdPxkEq+FVwWdPe3F2oS5J/iBGb sIC6EGdy/2sOMhcxC/E3Oz38u4YewPsySUwBM6XQcsFs7KK8OAXTn1hM+gWlPM6H ibtyIOV3aW/bF/Ww9PoqrzSJMjFh9FETYThdH8KYV9dKfGNisBz551xOiTCB17uX 9Ytz6NDqlz/OOEY+bKfEAYUhesb2D3xnwPVcNTnuoeeYJfbrFHPIfa9k5Wg0S0So LVK/RGlRJ4/fotpZ8t7d6cuEDBaRrcog/e0T4xgr2JYK4jSY5Kg4ws1WxA+1avQ= =DOM9 -----END PGP SIGNATURE----- --Apple-Mail=_6838806A-2549-465C-93C7-F7B14A15758C-- From nobody Wed Jun 25 01:29:28 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 614881B2AF6 for ; Wed, 25 Jun 2014 01:29:26 -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 AENa5Zv00gTK for ; Wed, 25 Jun 2014 01:29:20 -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 EFA391B2B0D for ; Wed, 25 Jun 2014 01:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5403; q=dns/txt; s=iport; t=1403684961; x=1404894561; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=3aJInI3lEtJPZvl0pMXnshYrAlVWzhZeTYAog4P5dWs=; b=RQkRusHg1wFJ7cSt5HhMq1UYPEJxOcGTLD8TVkF4GT1dTTUXkvvmASou E4QbqXnMF+5SNm23i7UmKf5t79K6y3YOP2647KUjxwQj6MX3QK5twsnmZ pTfbQdrg/sWM5sBXo/VXMjItewCAoX0e2Lb4WjVsfYf3ymGkW+0QLpjpr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYIAC+HqlOtJssW/2dsb2JhbABag19TiE+hPgUBkXoBhz8BgSZ1hAMBAQEEAQEBawoBEAsOCgkWDwkDAgECARUwBg0BBQIBAQWIOQgFyEQXhWOJGQcJhDoFmlGBRoU4jG2DRDs X-IronPort-AV: E=Sophos; i="5.01,544,1400025600"; d="scan'208,217"; a="93044930" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 25 Jun 2014 08:29:18 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5P8TH5x023918; Wed, 25 Jun 2014 08:29:17 GMT Message-ID: <53AA885D.2000105@cisco.com> Date: Wed, 25 Jun 2014 10:29:17 +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: Brian Trammell References: <20140624151844.4769.28603.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080707040507070902050309" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/AneyaLT-tMOEf2z7MfYU9F8ZH90 Cc: "Black, David" , ipfix@ietf.org Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-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: Wed, 25 Jun 2014 08:29:26 -0000 This is a multi-part message in MIME format. --------------080707040507070902050309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, This document is now on the IESG telechat on July 10th. Regards, Benoit > Greetings, all, > > This revision addresses GEN-ART review comments, and is IMO ready for write up and publication. > > Best regards, > > Brian > > On 24 Jun 2014, at 17:18, 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 : Textual Representation of IPFIX Abstract Data Types >> Author : Brian Trammell >> Filename : draft-ietf-ipfix-text-adt-06.txt >> Pages : 12 >> Date : 2014-06-24 >> >> 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-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-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 > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------080707040507070902050309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

This document is now on the IESG telechat on July 10th.

Regards, Benoit
Greetings, all,

This revision addresses GEN-ART review comments, and is IMO ready for write up and publication.

Best regards,

Brian

On 24 Jun 2014, at 17:18, 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           : Textual Representation of IPFIX Abstract Data Types
       Author          : Brian Trammell
	Filename        : draft-ietf-ipfix-text-adt-06.txt
	Pages           : 12
	Date            : 2014-06-24

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-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-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


      

      

      

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


    

    

  


--------------080707040507070902050309--