From nobody Wed Mar 1 01:37:15 2017 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E15D1298BA; Wed, 1 Mar 2017 01:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLSv-FC_gF7V; Wed, 1 Mar 2017 01:37:05 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDA31298A9; Wed, 1 Mar 2017 01:37:05 -0800 (PST) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v219WQnH011014; Wed, 1 Mar 2017 01:37:04 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 28wu5er2pa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 Mar 2017 01:37:03 -0800 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Mar 2017 02:37:00 -0700 Received: from [172.27.212.166] (172.27.212.166) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Mar 2017 10:36:56 +0100 To: "ipfix@ietf.org" , opsawg From: PJ Aitken Message-ID: <4b14effd-0c85-84ff-36a4-914d8cee2462@brocade.com> Date: Wed, 1 Mar 2017 09:36:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.27.212.166] X-ClientProxiedBy: hq1wp-excas14.corp.brocade.com (10.70.38.103) To EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-01_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1703010088 Archived-At: Subject: [IPFIX] draft-aitken-ipfix-pre-defined-templates X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:37:06 -0000 FYI, I've submitted a new draft: This document specifies a way to pre-define well-known IPFIX Templates which can be pre-shared with Collectors, thus avoiding the need for Exporters to send those Templates to Collectors. This saves export bandwidth and reduces Collector complexity. https://www.ietf.org/id/draft-aitken-ipfix-pre-defined-templates-00.txt P. From nobody Thu Mar 2 07:16:06 2017 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309C2129996; Thu, 2 Mar 2017 07:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v57NAspoXIiN; Thu, 2 Mar 2017 07:16:04 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4587C1297F1; Thu, 2 Mar 2017 07:16:04 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 73D501E32D; Thu, 2 Mar 2017 10:21:54 -0500 (EST) Date: Thu, 2 Mar 2017 10:21:54 -0500 From: Jeffrey Haas To: "lizhenqiang@chinamobile.com" Message-ID: <20170302152153.GD24913@pfrc.org> References: <7023a95c-c6a9-4d6a-b009-8f35e447aa4e@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357F4EA@NKGEML515-MBX.china.huawei.com> <2017021611151726192539@chinamobile.com> <2017021710323644287217@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2017021710323644287217@chinamobile.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "ipfix@ietf.org" , grow , opsawg-chairs , opsawg Subject: Re: [IPFIX] [GROW] [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 15:16:05 -0000 My original response to IDR and opsawg missed this thread on grow. I believe most of my concerns are covered in this thread and I don't require a separate answer. :-) On Mon, Feb 20, 2017 at 04:58:32PM +0800, lizhenqiang@chinamobile.com wrote: > Thank you for you opinion. The extended and large communities will be considered after the adoption and according to the working group consensus. FWIW, I agree with your assessment that extended communities are less likely to be important to your use case. However, large communities will very quickly become just as important. > Please see the appendix in the draft for the example. bgpDestinationCommunityList is a basicList of bgpCommunity. > > If you don't like the BGP communities according to the source IP of a specific flow, you can indicate it in the templete, i.e. do not specify bgpSourceCommunityList IE in the templete set. Then the exporter will not export the information. I do believe you'll need to figure out what to do about overflow of too many communities. As suggested in my other response, please consider prioritizing the inclusion of the well-known communities. > bgpSourceCommunityList does have values in some network environments. For example, the overalll network of China Mobile consists of a backbone network and several province networks. Each component network is configured with a few communities. BGP anounces those communities among the component networks. When one province wants to know where (i.e. from which provinces) its incoming traffic comes from, it can use bgpSourceCommunityList. However, this still causes you difficulty for BGP multipath scenarios. -- Jeff From nobody Fri Mar 3 02:43:00 2017 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDAC12942F; Fri, 3 Mar 2017 02:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4xcTZM9d_s3; Fri, 3 Mar 2017 02:42:58 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9236F126CD8; Fri, 3 Mar 2017 02:42:55 -0800 (PST) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v23AgE3A002745; Fri, 3 Mar 2017 02:42:54 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 28xshrtq8g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 03 Mar 2017 02:42:54 -0800 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 03:42:52 -0700 Received: from [10.252.49.6] (10.252.49.6) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 11:42:47 +0100 References: <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr> To: "draft-irtf-nmrg-location-ipfix.authors@ietf.org" From: PJ Aitken Message-ID: <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> Date: Fri, 3 Mar 2017 10:42:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.252.49.6] X-ClientProxiedBy: hq1wp-excas13.corp.brocade.com (10.70.36.103) To EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-03_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703030098 Archived-At: Cc: "opsawg-chairs@ietf.org" , "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:42:59 -0000 Authors, has this document been reviewed by any IPFIX experts? I see a request on November 23rd, but no reviews. So let me sign up for that. First, I took a quick look at the Figures in Appendix B: Figure 1: the Field Count should be 5, not 2. Figure 2: the size of the optional Padding field is wrong: the figure shows 9 bits rather than 8. Figure 4: the Length of 32 should be 28. The "geospatialLocationPosLat" Information Element isn't defined. Figure 5: the Field Count of 2 should be 3. Figure 7: The "geospatialLocationPostLng" and "geospatialLocationtLng" Information Elements aren't defined. Figure 9: The sizes of the "CivicValue" data fields are not shown correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it should contain 21. Therefore the Figure is misleading and difficult to understand; it is not a good example. Please redraw the figure correctly. Please mark the variable-lengths eg "vlen = 21". Figure 11: The Set IDs (311, 312, 313) do not correspond to the Template IDs in Figure 10 (306, 307, 308). Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 octets rather than the requisite 27. Without the repeated "Grand", the 21 would be correct. Please write "vlen=21" The "Civic location Attr length" of 25 seems wrong. This document is not ready for publication. Please post an updated version so I can check that all the IPFIX details are correct. Thanks, P. From nobody Fri Mar 3 03:02:16 2017 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8F11294F0; Fri, 3 Mar 2017 03:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cotnZy3GdAMH; Fri, 3 Mar 2017 03:02:05 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90661296CB; Fri, 3 Mar 2017 03:02:01 -0800 (PST) From: Abdelkader Lahmadi X-IronPort-AV: E=Sophos;i="5.35,236,1484002800"; d="asc'?scan'208";a="215438926" Received: from nat1-eduroam-montet.wifi.univ-lorraine.fr (HELO [10.10.105.59]) ([193.50.135.193]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2017 12:01:59 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_964EAC82-E206-40BC-9525-51FD0BF1E506"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 In-Reply-To: <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> Date: Fri, 3 Mar 2017 12:01:59 +0100 Message-Id: <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr> References: <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr> <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> To: PJ Aitken X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "draft-irtf-nmrg-location-ipfix.authors@ietf.org" , "Eggert, Lars" , "opsawg-chairs@ietf.org" , "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 11:02:15 -0000 --Apple-Mail=_964EAC82-E206-40BC-9525-51FD0BF1E506 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, We haven=E2=80=99t really get a "proper review" of the document by IPFIX = experts. Recently, we had a discussion with IANA and they asked = IE-doctors to make a review, since that we received some points to be = fixed regarding the proposed IE. I can forward to you the other comments = from IE-doctors that we have received by IANA. Thank you for your comments, Ok we will fix the raised issues in the = document. Best regards. > On 03 Mar 2017, at 11:42, PJ Aitken wrote: >=20 > Authors, has this document been reviewed by any IPFIX experts? >=20 > I see a request on November 23rd, but no reviews. So let me sign up = for that. >=20 >=20 > First, I took a quick look at the Figures in Appendix B: >=20 > Figure 1: the Field Count should be 5, not 2. >=20 > Figure 2: the size of the optional Padding field is wrong: the figure = shows 9 bits rather than 8. >=20 > Figure 4: the Length of 32 should be 28. The = "geospatialLocationPosLat" Information Element isn't defined. >=20 > Figure 5: the Field Count of 2 should be 3. >=20 > Figure 7: The "geospatialLocationPostLng" and "geospatialLocationtLng" = Information Elements aren't defined. >=20 > Figure 9: The sizes of the "CivicValue" data fields are not shown = correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it = should contain 21. Therefore the Figure is misleading and difficult to = understand; it is not a good example. Please redraw the figure = correctly. Please mark the variable-lengths eg "vlen =3D 21". >=20 > Figure 11: > The Set IDs (311, 312, 313) do not correspond to the Template IDs = in Figure 10 (306, 307, 308). > Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 = octets rather than the requisite 27. Without the repeated "Grand", the = 21 would be correct. Please write "vlen=3D21" > The "Civic location Attr length" of 25 seems wrong. >=20 >=20 > This document is not ready for publication. Please post an updated = version so I can check that all the IPFIX details are correct. >=20 > Thanks, > P. --Apple-Mail=_964EAC82-E206-40BC-9525-51FD0BF1E506 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 iQIcBAEBCgAGBQJYuU0nAAoJEBX1Mi7AAzI69l8P/0586ZzqVhUAhRWi/pi7vg+8 QwMfuKFN94iGa2lPBxxGO4UHdMOPiTcO6v4+cc7tu4PL1nqNOXmoeLWFoBSnL/uE bTvjSg7E3hI1n0SkO7axyMVDtK19L80vzPBVMOdj8nrR1mtXjZ3s0FGV+8Y6XEHR 4Ncft/Hg1fCNlS/RV1+BpIz2Y2mKF4KfyFeAR9OWnZYVsrrguekpObONgCXyreC5 dWpZ25x8Gy5Fst2+M76p6iiMiD0QOe3JjujRGtRrdg5ZquMxIydx/TMPDBQKdhHP 9f1iqCHECxEPhF5ZyCKNJgj5R+73JBgmoMnjmWASm/W2l5HXOfjREwmdrzmZRzqO gMUMiT6Y9I4My6XubUmv1OVE2TWTPiW5ABMXJ9S1XmnWZJD9pRIsYd4szSt3eiOU VwPMmG1MZIfGcfQgugSbimuOuL/euJRPy9pvE1PqonGFh4pWFyGEgkwPy3orSLjl mzjOrg4GvcAbKWOC42MvdHESC4dv7CCOl/ojaof9IsPShICqJXNd6tStO2iaa8hG hN1ub9T6MR122Lq2Oa9+k+c24loTrKeFXFz3j9up4Fo5BxOtJU1KjCv0rkJtH1Iy d43IGEqpYPhpuBcWA2U12nNFNtietMgveopQzVQzIB7Bt+tf13XEPZTT1rHqIIuD uYh3fVLDoyUsm8Z4gR/6 =NRzx -----END PGP SIGNATURE----- --Apple-Mail=_964EAC82-E206-40BC-9525-51FD0BF1E506-- From nobody Fri Mar 3 03:08:04 2017 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680031296C5; Fri, 3 Mar 2017 03:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnxqFf7Poynz; Fri, 3 Mar 2017 03:08:01 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980D6129687; Fri, 3 Mar 2017 03:08:01 -0800 (PST) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v23B3WZg019242; Fri, 3 Mar 2017 03:08:00 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 28xshktv1f-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 03 Mar 2017 03:08:00 -0800 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 04:07:55 -0700 Received: from [10.252.49.6] (10.252.49.6) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 12:07:27 +0100 To: Abdelkader Lahmadi References: <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr> <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr> From: PJ Aitken Message-ID: Date: Fri, 3 Mar 2017 11:07:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.252.49.6] X-ClientProxiedBy: hq1wp-excas14.corp.brocade.com (10.70.38.103) To EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-03_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703030105 Archived-At: Cc: "draft-irtf-nmrg-location-ipfix.authors@ietf.org" , "Eggert, Lars" , "opsawg-chairs@ietf.org" , "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 11:08:02 -0000 Abdelkader, it was me who did the IE-doctors review. That's only concerned with the IANA request; it's not an IPFIX review of the document. P. On 03/03/17 11:01, Abdelkader Lahmadi wrote: > Hello, > We haven’t really get a "proper review" of the document by IPFIX experts. Recently, we had a discussion with IANA and they asked IE-doctors to make a review, since that we received some points to be fixed regarding the proposed IE. I can forward to you the other comments from IE-doctors that we have received by IANA. > > Thank you for your comments, Ok we will fix the raised issues in the document. > Best regards. > > >> On 03 Mar 2017, at 11:42, PJ Aitken wrote: >> >> Authors, has this document been reviewed by any IPFIX experts? >> >> I see a request on November 23rd, but no reviews. So let me sign up for that. >> >> >> First, I took a quick look at the Figures in Appendix B: >> >> Figure 1: the Field Count should be 5, not 2. >> >> Figure 2: the size of the optional Padding field is wrong: the figure shows 9 bits rather than 8. >> >> Figure 4: the Length of 32 should be 28. The "geospatialLocationPosLat" Information Element isn't defined. >> >> Figure 5: the Field Count of 2 should be 3. >> >> Figure 7: The "geospatialLocationPostLng" and "geospatialLocationtLng" Information Elements aren't defined. >> >> Figure 9: The sizes of the "CivicValue" data fields are not shown correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it should contain 21. Therefore the Figure is misleading and difficult to understand; it is not a good example. Please redraw the figure correctly. Please mark the variable-lengths eg "vlen = 21". >> >> Figure 11: >> The Set IDs (311, 312, 313) do not correspond to the Template IDs in Figure 10 (306, 307, 308). >> Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 octets rather than the requisite 27. Without the repeated "Grand", the 21 would be correct. Please write "vlen=21" >> The "Civic location Attr length" of 25 seems wrong. >> >> >> This document is not ready for publication. Please post an updated version so I can check that all the IPFIX details are correct. >> >> Thanks, >> P. From nobody Fri Mar 3 03:18:02 2017 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D101129715; Fri, 3 Mar 2017 03:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQT6tJ6TBLfX; Fri, 3 Mar 2017 03:17:58 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0369E1296EE; Fri, 3 Mar 2017 03:17:57 -0800 (PST) From: Abdelkader Lahmadi X-IronPort-AV: E=Sophos;i="5.35,236,1484002800"; d="asc'?scan'208";a="262976026" Received: from nat1-eduroam-montet.wifi.univ-lorraine.fr (HELO [10.10.105.59]) ([193.50.135.193]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2017 12:17:56 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D518C538-25C7-43AF-89E1-8A92D629B949"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 In-Reply-To: Date: Fri, 3 Mar 2017 12:17:56 +0100 Message-Id: <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr> References: <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr> <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr> To: PJ Aitken X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "draft-irtf-nmrg-location-ipfix.authors@ietf.org" , "opsawg-chairs@ietf.org" , "Eggert, Lars" , "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 11:18:00 -0000 --Apple-Mail=_D518C538-25C7-43AF-89E1-8A92D629B949 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok, more clear now. So, we work on a new text to resolve ALL the raised issues and send you = a version. Best, > On 03 Mar 2017, at 12:07, PJ Aitken wrote: >=20 > Abdelkader, it was me who did the IE-doctors review. That's only = concerned with the IANA request; it's not an IPFIX review of the = document. >=20 > P. >=20 >=20 > On 03/03/17 11:01, Abdelkader Lahmadi wrote: >> Hello, >> We haven=E2=80=99t really get a "proper review" of the document by = IPFIX experts. Recently, we had a discussion with IANA and they asked = IE-doctors to make a review, since that we received some points to be = fixed regarding the proposed IE. I can forward to you the other comments = from IE-doctors that we have received by IANA. >>=20 >> Thank you for your comments, Ok we will fix the raised issues in the = document. >> Best regards. >>=20 >>=20 >>> On 03 Mar 2017, at 11:42, PJ Aitken wrote: >>>=20 >>> Authors, has this document been reviewed by any IPFIX experts? >>>=20 >>> I see a request on November 23rd, but no reviews. So let me sign up = for that. >>>=20 >>>=20 >>> First, I took a quick look at the Figures in Appendix B: >>>=20 >>> Figure 1: the Field Count should be 5, not 2. >>>=20 >>> Figure 2: the size of the optional Padding field is wrong: the = figure shows 9 bits rather than 8. >>>=20 >>> Figure 4: the Length of 32 should be 28. The = "geospatialLocationPosLat" Information Element isn't defined. >>>=20 >>> Figure 5: the Field Count of 2 should be 3. >>>=20 >>> Figure 7: The "geospatialLocationPostLng" and = "geospatialLocationtLng" Information Elements aren't defined. >>>=20 >>> Figure 9: The sizes of the "CivicValue" data fields are not shown = correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it = should contain 21. Therefore the Figure is misleading and difficult to = understand; it is not a good example. Please redraw the figure = correctly. Please mark the variable-lengths eg "vlen =3D 21". >>>=20 >>> Figure 11: >>> The Set IDs (311, 312, 313) do not correspond to the Template IDs = in Figure 10 (306, 307, 308). >>> Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 = octets rather than the requisite 27. Without the repeated "Grand", the = 21 would be correct. Please write "vlen=3D21" >>> The "Civic location Attr length" of 25 seems wrong. >>>=20 >>>=20 >>> This document is not ready for publication. Please post an updated = version so I can check that all the IPFIX details are correct. >>>=20 >>> Thanks, >>> P. >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_D518C538-25C7-43AF-89E1-8A92D629B949 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 iQIcBAEBCgAGBQJYuVDkAAoJEBX1Mi7AAzI66WIQAKHCI8ngHskuBBJkJR42VUFO uFhzEWE+roZz0KR6Z320gz7I7zgJGiu0FzZDiuCAp5fwgsYnU6Qpp9H+ODto3t7P ejJ55DKDkAJQasr4HZQFZenD4UyxWaeLAMRgr2PBCK+KCkVoxrArqPd/mfsQ76sp OklMivb/wKk8T5MsDB+KKdCvbMbTAY4XdBI9IsymtaqfNSdPSgorHIJTCI9ndRRG jM/gJEvF5nLfegYIKULmwYyINZbORUt0xIPUG2McfFcpSLEkpxNW3ZyIruQg/LiW p5B9V0OOUPH8n7q/YlQg+JWUh0DCdiLBg0JAPuIAIEBHkDwLfIZnWCYRA59G3phP UFdfYI8/f1eDT16mC9Mu2s5Den/TdpS/EqBlX/wSjDseG90Cgz366+Ke1Zdt/ir9 RQGu3ZVJG+ioLtNsuNzfBXqUS0GDqH6FA+Fx2ox1+jJuAgBe7t0LXUuxocZGL5Xd PYpOJMjDnMST9dA2CXhOcRIaRXgSK+PndXQ/Q7T7PvGWYJo/FHwUwPP68swFkjET 7qXxE+/csxQRlhDY8+Ag/GoUpiOTMZXWKD2+nlDy7m479OIwZAujF6uugzeOnTVc ntyDKlq/A4R4mwHUZLzjaoWOlkuDQVwT38ohiwetBPX6ea6oLU81NHlhmnX5hUAw LYFR4VDBYFxNzhYua3F9 =X1dz -----END PGP SIGNATURE----- --Apple-Mail=_D518C538-25C7-43AF-89E1-8A92D629B949-- From nobody Fri Mar 3 03:26:42 2017 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9A1297ED; Fri, 3 Mar 2017 03:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgAEqkFgYc8i; Fri, 3 Mar 2017 03:26:39 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74DC1296F0; Fri, 3 Mar 2017 03:26:39 -0800 (PST) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v23BQA2M016073; Fri, 3 Mar 2017 03:26:39 -0800 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 28xshuk031-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 03 Mar 2017 03:26:39 -0800 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 04:26:36 -0700 Received: from [10.252.49.6] (10.252.49.6) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 12:26:30 +0100 To: Abdelkader Lahmadi References: <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr> <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr> <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr> From: PJ Aitken Message-ID: Date: Fri, 3 Mar 2017 11:26:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr> Content-Type: multipart/alternative; boundary="------------EB37E06F49CFE2F45FDCA17B" X-Originating-IP: [10.252.49.6] X-ClientProxiedBy: hq1wp-excas11.corp.brocade.com (10.70.36.102) To EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-03_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703030102 Archived-At: Cc: "draft-irtf-nmrg-location-ipfix.authors@ietf.org" , "Eggert, Lars" , "opsawg-chairs@ietf.org" , "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 11:26:41 -0000 --------------EB37E06F49CFE2F45FDCA17B Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Great, thanks. P. On 03/03/17 11:17, Abdelkader Lahmadi wrote: > Ok, more clear now. > So, we work on a new text to resolve ALL the raised issues and send you a version. > > Best, >> On 03 Mar 2017, at 12:07, PJ Aitken wrote: >> >> Abdelkader, it was me who did the IE-doctors review. That's only concerned with the IANA request; it's not an IPFIX review of the document. >> >> P. >> >> >> On 03/03/17 11:01, Abdelkader Lahmadi wrote: >>> Hello, >>> We haven’t really get a "proper review" of the document by IPFIX experts. Recently, we had a discussion with IANA and they asked IE-doctors to make a review, since that we received some points to be fixed regarding the proposed IE. I can forward to you the other comments from IE-doctors that we have received by IANA. >>> >>> Thank you for your comments, Ok we will fix the raised issues in the document. >>> Best regards. >>> >>> >>>> On 03 Mar 2017, at 11:42, PJ Aitken wrote: >>>> >>>> Authors, has this document been reviewed by any IPFIX experts? >>>> >>>> I see a request on November 23rd, but no reviews. So let me sign up for that. >>>> >>>> >>>> First, I took a quick look at the Figures in Appendix B: >>>> >>>> Figure 1: the Field Count should be 5, not 2. >>>> >>>> Figure 2: the size of the optional Padding field is wrong: the figure shows 9 bits rather than 8. >>>> >>>> Figure 4: the Length of 32 should be 28. The "geospatialLocationPosLat" Information Element isn't defined. >>>> >>>> Figure 5: the Field Count of 2 should be 3. >>>> >>>> Figure 7: The "geospatialLocationPostLng" and "geospatialLocationtLng" Information Elements aren't defined. >>>> >>>> Figure 9: The sizes of the "CivicValue" data fields are not shown correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it should contain 21. Therefore the Figure is misleading and difficult to understand; it is not a good example. Please redraw the figure correctly. Please mark the variable-lengths eg "vlen = 21". >>>> >>>> Figure 11: >>>> The Set IDs (311, 312, 313) do not correspond to the Template IDs in Figure 10 (306, 307, 308). >>>> Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 octets rather than the requisite 27. Without the repeated "Grand", the 21 would be correct. Please write "vlen=21" >>>> The "Civic location Attr length" of 25 seems wrong. >>>> >>>> >>>> This document is not ready for publication. Please post an updated version so I can check that all the IPFIX details are correct. >>>> >>>> Thanks, >>>> P. >> _______________________________________________ >> 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 --------------EB37E06F49CFE2F45FDCA17B Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Great, thanks.

P.

On 03/03/17 11:17, Abdelkader Lahmadi wrote:
Ok, more clear now.
So, we work on a new text to resolve ALL the raised issues and send you a version.

Best,

On 03 Mar 2017, at 12:07, PJ Aitken <pjaitken@brocade.com> wrote:

Abdelkader, it was me who did the IE-doctors review. That's only concerned with the IANA request; it's not an IPFIX review of the document.

P.


On 03/03/17 11:01, Abdelkader Lahmadi wrote:

Hello,
We haven’t really get a "proper review" of the document by IPFIX experts. Recently, we had a discussion with IANA and they asked IE-doctors to make a review, since that we received some points to be fixed regarding the proposed IE. I can forward to you the other comments from IE-doctors that we have received by IANA.

Thank you for your comments, Ok we will fix the raised issues in the document.
Best regards.



On 03 Mar 2017, at 11:42, PJ Aitken <pjaitken@brocade.com> wrote:

Authors, has this document been reviewed by any IPFIX experts?

I see a request on November 23rd, but no reviews. So let me sign up for that.


First, I took a quick look at the Figures in Appendix B:

Figure 1: the Field Count should be 5, not 2.

Figure 2: the size of the optional Padding field is wrong: the figure shows 9 bits rather than 8.

Figure 4: the Length of 32 should be 28. The "geospatialLocationPosLat" Information Element isn't defined.

Figure 5: the Field Count of 2 should be 3.

Figure 7: The "geospatialLocationPostLng" and "geospatialLocationtLng" Information Elements aren't defined.

Figure 9: The sizes of the "CivicValue" data fields are not shown correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it should contain 21. Therefore the Figure is misleading and difficult to understand; it is not a good example. Please redraw the figure correctly. Please mark the variable-lengths eg "vlen = 21".

Figure 11:
   The Set IDs (311, 312, 313) do not correspond to the Template IDs in Figure 10 (306, 307, 308).
   Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 octets rather than the requisite 27. Without the repeated "Grand", the 21 would be correct. Please write "vlen=21"
   The "Civic location Attr length" of 25 seems wrong.


This document is not ready for publication. Please post an updated version so I can check that all the IPFIX details are correct.

Thanks,
P.

_______________________________________________
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


    

    

  


--------------EB37E06F49CFE2F45FDCA17B--


From nobody Fri Mar  3 03:38:09 2017
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D4A1297D4; Fri,  3 Mar 2017 03:38:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com
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 k85NKC5GSbYq; Fri,  3 Mar 2017 03:38:06 -0800 (PST)
Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF5D1294B0; Fri,  3 Mar 2017 03:29:45 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.35,236,1484035200";  d="asc'?scan'208";a="174698896"
Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 03 Mar 2017 03:19:31 -0800
Received: from VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 03:28:41 -0800
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Fri, 3 Mar 2017 03:28:41 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/Aa4BuvKLkc10bUaVi8PhxBAQI/qqWYNOnm/Zqzd5Fo=; b=m6lI9pSYTYlY5jWGxvWjVUJVsSQSsmBFvLgePb9oWK3xvONUeUKAob1q1jTovGUBXOpg5IWEnbiiXrNvnyLypNhcK3orHFlhu3gr6AswUYnGy0DRGLluE/vu+HFSaicWkxxyra5VzOgbhyX6LkfjPVgQOSQjEBOhGfIRUb4AB/A=
Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 3 Mar 2017 11:28:40 +0000
Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0933.020; Fri, 3 Mar 2017 11:28:39 +0000
From: "Eggert, Lars" 
To: Abdelkader Lahmadi 
Thread-Topic: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
Thread-Index: AQHSlA2rRN1dx6gTP0qxqcp8ZIxXXaGC9I4AgAAC9ACAAAL6AA==
Date: Fri, 3 Mar 2017 11:28:39 +0000
Message-ID: <6AA4BDC1-D371-4576-9C5D-BBC49391095B@netapp.com>
References:  <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr>  <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr>  <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr>
In-Reply-To: <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3259)
authentication-results: loria.fr; dkim=none (message not signed) header.d=none;loria.fr; dmarc=none action=none header.from=netapp.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [217.70.211.15]
x-ms-office365-filtering-correlation-id: f0c7a1a8-ad28-4598-31e0-08d4622870d2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1154; 
x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:CEEc+7Fkn6Vql5XPK71Mn6qFSnbiIF0raUbRKcR2239CaVsR1zcPNaWrbY2pQTwUJDoFPB453CEccPTkN4eyI/GpClXiYse/LeJnsSkSC18bYUSpEBRIs+BF6thl2WEy5fJ7sm/pDim4P0Q5etIKw6U4GVy6iX74IgHXO1+Uetpo3ZoegdQqZdVRlgr1rIhPzNfY5dUJHgDzcGj5q/uQ6ngsjLc9CiOP/kJ6ZyUyxuz8FqZzzcJJKoM1h9si5LfYTqQlJ2kqyB7uAOGbJx82gBU4DSfrBq0v49FFI1PKj0KHbW/ZS8SJG2sY5M68rYdDx+qNfmU8UzXgbotHQ+bXLA==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(131327999870524);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; 
x-forefront-prvs: 0235CBE7D0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377424004)(24454002)(3660700001)(83716003)(99286003)(76176999)(6512007)(7736002)(305945005)(92566002)(33656002)(82746002)(54906002)(66066001)(86362001)(6506006)(4326008)(2906002)(4001150100001)(2900100001)(3280700002)(6306002)(99936001)(122556002)(3846002)(57306001)(50986999)(2950100002)(5660300001)(6116002)(102836003)(6916009)(93886004)(25786008)(53546006)(106116001)(36756003)(189998001)(53936002)(230783001)(81166006)(6486002)(8676002)(6436002)(77096006)(50226002)(229853002)(345774005)(8936002)(110136004)(38730400002)(6246003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_0971731A-A90C-420D-A001-711BCAEB8259"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 11:28:39.4619 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154
X-OriginatorOrg: netapp.com
Archived-At: 
Cc: "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" , "Internet Research Steering Group \(irsg@irtf.org\)" , "draft-irtf-nmrg-location-ipfix.authors@ietf.org" , "opsawg-chairs@ietf.org" , PJ Aitken 
Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Mar 2017 11:38:08 -0000

--Apple-Mail=_0971731A-A90C-420D-A001-711BCAEB8259
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On 2017-3-3, at 12:17, Abdelkader Lahmadi  =
wrote:
> So, we work on a new text to resolve ALL the raised issues and send =
you a version.

Hang on. Your RG chair should have explained how the process works.

This IRTF document is now being reviewed (per RFC5742) by the IESG. That =
review is *not* the same review that happens for IETF documents. =
Specifically, the IESG can really only say one of these five things:

>    1. The IESG has concluded that there is no conflict between this
>       document and IETF work.
>=20
>    2. The IESG has concluded that this work is related to IETF work =
done
>       in WG , but this relationship does not prevent publishing.
>=20
>    3. The IESG has concluded that publication could potentially =
disrupt
>       the IETF work done in WG  and recommends not publishing the
>       document at this time.
>=20
>    4. The IESG has concluded that this document violates IETF =
procedures
>       for  and should therefore not be published without IETF =
review
>       and IESG approval.
>=20
>    5. The IESG has concluded that this document extends an IETF =
protocol
>       in a way that requires IETF review and should therefore not be
>       published without IETF review and IESG approval.


At the moment, you are getting individual comments from IPFIX experts as =
part of the IANA review process of the registry actions your document =
wants to make happen. Those are very valuable (thank you!), but before =
you make any changes to the document, please wait until an Area Director =
says that the issues raised are at a significance where they will ask =
for an IESG response other than #1 or #2 above.

It sounds like this is likely going to be the case here, but please wait =
until the ADs have caught up on the discussion. And please wait with =
submitting a new revision until that happens as well.

Lars


>=20
> Best,
>> On 03 Mar 2017, at 12:07, PJ Aitken  wrote:
>>=20
>> Abdelkader, it was me who did the IE-doctors review. That's only =
concerned with the IANA request; it's not an IPFIX review of the =
document.
>>=20
>> P.
>>=20
>>=20
>> On 03/03/17 11:01, Abdelkader Lahmadi wrote:
>>> Hello,
>>> We haven=E2=80=99t really get a "proper review" of the document by =
IPFIX experts. Recently, we had a discussion with IANA and they asked =
IE-doctors to make a review, since that we received some points to be =
fixed regarding the proposed IE. I can forward to you the other comments =
from IE-doctors that we have received by IANA.
>>>=20
>>> Thank you for your comments, Ok we will fix the raised issues in the =
document.
>>> Best regards.
>>>=20
>>>=20
>>>> On 03 Mar 2017, at 11:42, PJ Aitken  wrote:
>>>>=20
>>>> Authors, has this document been reviewed by any IPFIX experts?
>>>>=20
>>>> I see a request on November 23rd, but no reviews. So let me sign up =
for that.
>>>>=20
>>>>=20
>>>> First, I took a quick look at the Figures in Appendix B:
>>>>=20
>>>> Figure 1: the Field Count should be 5, not 2.
>>>>=20
>>>> Figure 2: the size of the optional Padding field is wrong: the =
figure shows 9 bits rather than 8.
>>>>=20
>>>> Figure 4: the Length of 32 should be 28. The =
"geospatialLocationPosLat" Information Element isn't defined.
>>>>=20
>>>> Figure 5: the Field Count of 2 should be 3.
>>>>=20
>>>> Figure 7: The "geospatialLocationPostLng" and =
"geospatialLocationtLng" Information Elements aren't defined.
>>>>=20
>>>> Figure 9: The sizes of the "CivicValue" data fields are not shown =
correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it =
should contain 21. Therefore the Figure is misleading and difficult to =
understand; it is not a good example. Please redraw the figure =
correctly. Please mark the variable-lengths eg "vlen =3D 21".
>>>>=20
>>>> Figure 11:
>>>>   The Set IDs (311, 312, 313) do not correspond to the Template IDs =
in Figure 10 (306, 307, 308).
>>>>   Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 =
octets rather than the requisite 27. Without the repeated "Grand", the =
21 would be correct. Please write "vlen=3D21"
>>>>   The "Civic location Attr length" of 25 seems wrong.
>>>>=20
>>>>=20
>>>> This document is not ready for publication. Please post an updated =
version so I can check that all the IPFIX details are correct.
>>>>=20
>>>> Thanks,
>>>> P.
>>=20
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>=20


--Apple-Mail=_0971731A-A90C-420D-A001-711BCAEB8259
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYuVNlAAoJEFS1wwm/cMFXCyQQAN2USnh7IugcG6nMNGie4Bze
hBeNWvSFUwRQAx1sEe3oUeCIJOHTuH6/gZT8GpVJrx1dxqT1Mw7pkOux9wv2Ue4g
wZoF+tbGIUlV6kPoti3X5VXfMWTCGK1kruRcbbArPihOavJt7LVOi4pzu5XM/JQu
0RqxarrwJiw701skcYmwqctYIzjwbXYTyhqlRdQVhbV9UJPANYd1aijw7lD9noza
GL6rLxY1hJNPmx1zWI3XzF12KBVc1ds1mUcyvPW5/hNndVuO/GLHX+W+kmGlX0mr
4K+MhzlkN0hkYtGLZ+wgPg7P0Ut+Q1/lHA4zc/jWRpogkSyBbZAlP1GcxKDtxTi8
iQmrTu6kmPBu4I2wrWIvNxzvRfsKYpG6wDgbObpQrnJHOjVKJc/oMqvhqMHUKSZa
p8ytL89NLBlNpiaeK64Cc4iS1CkX7vxmuQSfk+c7fLjGtfpbsPFfJTS2R6udg3L6
fuy1vJVjKUvrtKjK7EpEaG2/xkxyqH/XLt8Jg5p1dBkYBQ26cpDzugWM0wxO+gNc
LXOOQt2B4xF8A+Y6FVqZkP+gyqHUpJwHxUonlLJMgwzuTVAFj3O56ZEGls8ICgOM
lDJ8PPF5urSYT8LgHG5ft8egrWwFltKhXrrSh0L7MnlJUdabAbIMznyHOtn/5mno
OUPMuzJHhqbLIIK9cSjB
=03qA
-----END PGP SIGNATURE-----

--Apple-Mail=_0971731A-A90C-420D-A001-711BCAEB8259--


From nobody Fri Mar  3 04:16:22 2017
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9535A12984A; Fri,  3 Mar 2017 04:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC39WcIzbVzd; Fri,  3 Mar 2017 04:16:18 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD551297F7; Fri,  3 Mar 2017 04:16:17 -0800 (PST)
From: Abdelkader Lahmadi 
X-IronPort-AV: E=Sophos;i="5.35,237,1484002800";  d="asc'?scan'208";a="262984117"
Received: from nat1-eduroam-montet.wifi.univ-lorraine.fr (HELO [10.10.105.59]) ([193.50.135.193]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2017 13:16:15 +0100
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1CE8537D-846F-4ACD-BA24-AE46C5B938AA"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
In-Reply-To: <6AA4BDC1-D371-4576-9C5D-BBC49391095B@netapp.com>
Date: Fri, 3 Mar 2017 13:16:15 +0100
Message-Id: <86F000D5-245F-4D95-B600-15C4C6BFF444@loria.fr>
References:  <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr>  <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr>  <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr> <6AA4BDC1-D371-4576-9C5D-BBC49391095B@netapp.com>
To: "Eggert, Lars" 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" , "Internet Research Steering Group \(irsg@irtf.org\)" , "draft-irtf-nmrg-location-ipfix.authors@ietf.org" , "opsawg-chairs@ietf.org" , PJ Aitken 
Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Mar 2017 12:16:19 -0000

--Apple-Mail=_1CE8537D-846F-4ACD-BA24-AE46C5B938AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Ok. That=E2=80=99s clear. Thank you.
> On 03 Mar 2017, at 12:28, Eggert, Lars  wrote:
>=20
> On 2017-3-3, at 12:17, Abdelkader Lahmadi =
 wrote:
>> So, we work on a new text to resolve ALL the raised issues and send =
you a version.
>=20
> Hang on. Your RG chair should have explained how the process works.
>=20
> This IRTF document is now being reviewed (per RFC5742) by the IESG. =
That review is *not* the same review that happens for IETF documents. =
Specifically, the IESG can really only say one of these five things:
>=20
>>   1. The IESG has concluded that there is no conflict between this
>>      document and IETF work.
>>=20
>>   2. The IESG has concluded that this work is related to IETF work =
done
>>      in WG , but this relationship does not prevent publishing.
>>=20
>>   3. The IESG has concluded that publication could potentially =
disrupt
>>      the IETF work done in WG  and recommends not publishing the
>>      document at this time.
>>=20
>>   4. The IESG has concluded that this document violates IETF =
procedures
>>      for  and should therefore not be published without IETF =
review
>>      and IESG approval.
>>=20
>>   5. The IESG has concluded that this document extends an IETF =
protocol
>>      in a way that requires IETF review and should therefore not be
>>      published without IETF review and IESG approval.
>=20
>=20
> At the moment, you are getting individual comments from IPFIX experts =
as part of the IANA review process of the registry actions your document =
wants to make happen. Those are very valuable (thank you!), but before =
you make any changes to the document, please wait until an Area Director =
says that the issues raised are at a significance where they will ask =
for an IESG response other than #1 or #2 above.
>=20
> It sounds like this is likely going to be the case here, but please =
wait until the ADs have caught up on the discussion. And please wait =
with submitting a new revision until that happens as well.
>=20
> Lars
>=20
>=20
>>=20
>> Best,
>>> On 03 Mar 2017, at 12:07, PJ Aitken  wrote:
>>>=20
>>> Abdelkader, it was me who did the IE-doctors review. That's only =
concerned with the IANA request; it's not an IPFIX review of the =
document.
>>>=20
>>> P.
>>>=20
>>>=20
>>> On 03/03/17 11:01, Abdelkader Lahmadi wrote:
>>>> Hello,
>>>> We haven=E2=80=99t really get a "proper review" of the document by =
IPFIX experts. Recently, we had a discussion with IANA and they asked =
IE-doctors to make a review, since that we received some points to be =
fixed regarding the proposed IE. I can forward to you the other comments =
from IE-doctors that we have received by IANA.
>>>>=20
>>>> Thank you for your comments, Ok we will fix the raised issues in =
the document.
>>>> Best regards.
>>>>=20
>>>>=20
>>>>> On 03 Mar 2017, at 11:42, PJ Aitken  wrote:
>>>>>=20
>>>>> Authors, has this document been reviewed by any IPFIX experts?
>>>>>=20
>>>>> I see a request on November 23rd, but no reviews. So let me sign =
up for that.
>>>>>=20
>>>>>=20
>>>>> First, I took a quick look at the Figures in Appendix B:
>>>>>=20
>>>>> Figure 1: the Field Count should be 5, not 2.
>>>>>=20
>>>>> Figure 2: the size of the optional Padding field is wrong: the =
figure shows 9 bits rather than 8.
>>>>>=20
>>>>> Figure 4: the Length of 32 should be 28. The =
"geospatialLocationPosLat" Information Element isn't defined.
>>>>>=20
>>>>> Figure 5: the Field Count of 2 should be 3.
>>>>>=20
>>>>> Figure 7: The "geospatialLocationPostLng" and =
"geospatialLocationtLng" Information Elements aren't defined.
>>>>>=20
>>>>> Figure 9: The sizes of the "CivicValue" data fields are not shown =
correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it =
should contain 21. Therefore the Figure is misleading and difficult to =
understand; it is not a good example. Please redraw the figure =
correctly. Please mark the variable-lengths eg "vlen =3D 21".
>>>>>=20
>>>>> Figure 11:
>>>>>  The Set IDs (311, 312, 313) do not correspond to the Template IDs =
in Figure 10 (306, 307, 308).
>>>>>  Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 =
octets rather than the requisite 27. Without the repeated "Grand", the =
21 would be correct. Please write "vlen=3D21"
>>>>>  The "Civic location Attr length" of 25 seems wrong.
>>>>>=20
>>>>>=20
>>>>> This document is not ready for publication. Please post an updated =
version so I can check that all the IPFIX details are correct.
>>>>>=20
>>>>> Thanks,
>>>>> P.
>>>=20
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>=20
>=20


--Apple-Mail=_1CE8537D-846F-4ACD-BA24-AE46C5B938AA
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

iQIcBAEBCgAGBQJYuV6PAAoJEBX1Mi7AAzI6khwQAIrOSlLrRKz4DphlQwlJRHa+
Sxihq9Qp0qtzE2QiMXAslOex4an8o2rL5y23Z4iDboLuL4KxJotR5GuLYVWhoa3W
8mbXynZbhX81pKCZosDgvI/fEimskhhW27vtMn92pJnX9v+TSFnLFrFYRXVGrGUd
j5fLlb94dSdQdcZQXDUJEBzrxNZUiZ7udJkWXbNkv2fPFbu02TCIpqLN5PwvMZHb
NRStDxieqBIbBAy80XCu8C0aXCcERe0n8XvbGOa0OpcgHB1vxHhIsHiBshzqe2oi
7m9b/y+AHnIzO4se7keWpHz7e06LLrz8YUmyHLYXgLDGM3iI+dN9DhLX3gk+LyC2
3cCQHqJYunFjiZNRbbsNUsZwb1UPDgD8rns7RL9Ekq4olSCkE/M7ZEfpUTLPJ7AA
wKLKy4mGfAs5EfVUDCXCCfF62oie83l5KD6YeBu0MUyz23Muab7SgHj0ef/ouvbJ
KwOrRqqagvV7/JHdpA8kCP+LHXwBd268gE6sezLYJb/32Xd7WvMa7FKW3SEVtKAj
S7ofCn/diLI/vW2n4aJFQmdcpnu3cTTbwEK4jsEKjJ+kbikihFWQs8SUc3XW3qz5
Ur1DAar+BieQ7bRH9h/l1pptX7W4xhgl647HQv+bxeP4RjrNTm+bwLNIeNCItkI7
kEiOK7M/l/mw0W10qE5S
=kpof
-----END PGP SIGNATURE-----

--Apple-Mail=_1CE8537D-846F-4ACD-BA24-AE46C5B938AA--


From nobody Sat Mar  4 08:21:57 2017
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B191294E7; Sat,  4 Mar 2017 08:21:55 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=calix.onmicrosoft.com
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 1D0MiOlFyvtL; Sat,  4 Mar 2017 08:21:54 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0015.outbound.protection.outlook.com [207.46.163.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B9F12949F; Sat,  4 Mar 2017 08:21:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CALIX.onmicrosoft.com;  s=selector1-calix-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ufnsz5F5hwp3tC/D4YDgQ+ujarjIkXLnBuHHsgg4at8=; b=BMwjySvF/S8A1HZIDEzmTEzLUj/JTGIlIL2Sty6MDpV2gCpBXSMr8RoJ/CcVbjxWFtKEc/02o6MGwcdq/7FoM5xGRKxckIOpw7uui3wc7opr52h3BdaO2EyYMzsJllmAaoaU4LBcNOjZ7cg5PzYTpeAY2dcLNhIIRVwUwv6D+LM=
Received: from BY2PR0501MB1734.namprd05.prod.outlook.com (10.163.154.20) by BY2PR0501MB1735.namprd05.prod.outlook.com (10.163.154.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Sat, 4 Mar 2017 16:21:51 +0000
Received: from BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) by BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) with mapi id 15.01.0947.018; Sat, 4 Mar 2017 16:21:51 +0000
From: Marta Seda 
To: "ipfix@ietf.org" , "ie-doctors@ietf.org" 
Thread-Topic: RFC 6728:  Observation Point ID definition
Thread-Index: AdKVAG16Yvmjgq+WSyWTyKVdbi34RQ==
Date: Sat, 4 Mar 2017 16:21:51 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=calix.com;
x-originating-ip: [23.118.53.86]
x-ms-office365-filtering-correlation-id: e602cd53-c1fb-4117-fcf4-08d4631a90f4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0501MB1735; 
x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1735; 7:+cphoyylmxHpp7gUFhPqOOaWr4C06NykigraDKARWCvSTIESSdksm+nvljzEGudiUK79ucjdQa3pHfVKgZmiMurMK447Ks6BPtPhqtITllfLXGz/HcABTTm5x4aiUGKpMUiygIdi6Ytdor3qjKI0Iy47KeSlAVOf/tOCmuKZPADr1AzjHWt6B1v2Hq0mY1j0vS2gWPHRN0kRb2V3LWNWEPA6ZrJYfy/yTjroULxdFQCiNef99AETgAvzc0cuI9R26VtmlzuczaeCF36wZ8D6Sm/IBwbwaJY8Zc3DFYWzMZN7s8GXILEDeMdVc0voIKB6ZMBcafuhStkdW6o5oNh3aQ==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(20558992708506)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(6072148); SRVR:BY2PR0501MB1735; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1735; 
x-forefront-prvs: 0236114672
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(38730400002)(92566002)(9686003)(122556002)(54896002)(86362001)(6306002)(2501003)(189998001)(3280700002)(99286003)(3660700001)(2906002)(2900100001)(25786008)(3846002)(102836003)(66066001)(790700001)(6436002)(8676002)(81166006)(7736002)(6506006)(53936002)(77096006)(9326002)(5660300001)(55016002)(450100001)(8936002)(74316002)(7696004)(54356999)(33656002)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0501MB1735; H:BY2PR0501MB1734.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR0501MB17346D370676D56617BC67A49C2A0BY2PR0501MB1734_"
MIME-Version: 1.0
X-OriginatorOrg: calix.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2017 16:21:51.4762 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ffae2e5-6ff0-4510-bbf3-ca842d7ca55e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1735
Archived-At: 
Subject: [IPFIX] RFC 6728:  Observation Point ID definition
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 Mar 2017 16:21:55 -0000

--_000_BY2PR0501MB17346D370676D56617BC67A49C2A0BY2PR0501MB1734_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

RFC 6728 defines the observation point as the "location for which packets a=
re observed".  RFC 6727 page 4.1 shows this uml relationship:

         +-------------------------------+
         | ObservationPoint              |
         +-------------------------------+
         | name                          |
         | observationPointId {readOnly} |
         | observationDomainId           | 0..*
         | ifName[0..*]                  |-------------+
         | ifIndex[0..*]                 |             | 0..*
         | entPhysicalName[0..*]         |             V
         | entPhysicalIndex[0..*]        |    +------------------+
         | direction =3D "both"            |    | SelectionProcess |
         +-------------------------------+    +------------------+


In RFC 6728, the observationpointid, ifname, ifindex,entphysicalname and en=
tphysicalindex are part of the observationpointparameters grouping.

RFC 6728 has examples centered around the idea of creating a metering proce=
ss that samples packets and reports statistics over ipfix (netflow-like sta=
tistics).

There is yang models that configure statistic collection.   It seems in tha=
t case (if you want to use ipfix to carry those statistics), that the obser=
vation point could refer to those entities (leaf-ref) that are already coll=
ecting statistics.  When I look at the RFC 6728 yang structure it seems the=
re is an "attempt" to do that via the use of IfName, IfIndex, EntPhysicalNa=
me and EntPhysicalIndex (which are SNMP physical entities).  However you ha=
ve logical entities that the current structure doesn't permit you to define=
 as the observation points.  Is that a correct interpretation of the curren=
t yang for ipfix?  How can you refer to logical entities? (it seems the onl=
y place you could do this was to stick the leaf-ref into the name but not a=
 good yang practice).

Please advise.

Thanks.

Marta Seda



--_000_BY2PR0501MB17346D370676D56617BC67A49C2A0BY2PR0501MB1734_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello,


 


RFC 6728 defines the observation point as the “=
;location for which packets are observed”.  RFC 6727 page 4.1 sh=
ows this uml relationship:


 


       &nbs=
p; +-------------------------------+


       &nbs=
p; | ObservationPoint         =
     |


        &nb=
sp;+-------------------------------+


       &nbs=
p; | name           =
            &nb=
sp;  |


       &nbs=
p; | observationPointId {readOnly} |


       &nbs=
p; | observationDomainId        &nb=
sp;  | 0..*


       &nbs=
p; | ifName[0..*]         &nbs=
p;        |-------------+=



       &nbs=
p; | ifIndex[0..*]         &nb=
sp;       |     &nbs=
p;       | 0..*


       &nbs=
p; | entPhysicalName[0..*]         =
|             V=



       &nbs=
p; | entPhysicalIndex[0..*]        |&nbs=
p;   +------------------+


       &nbs=
p; | direction =3D "both"      &nbs=
p;     |    | SelectionProcess |


       &nbs=
p; +-------------------------------+    +-------=
-----------+


 


 


In RFC 6728, the observationpointid, ifname, ifindex=
,entphysicalname and entphysicalindex are part of the observationpointparam=
eters grouping.


 


RFC 6728 has examples centered around the idea of cr=
eating a metering process that samples packets and reports statistics over =
ipfix (netflow-like statistics). 



 


There is yang models that configure statistic collec=
tion.   It seems in that case (if you want to use ipfix to carry =
those statistics), that the observation point could refer to those entities=
 (leaf-ref) that are already collecting statistics.
  When I look at the RFC 6728 yang structure it seems there is an R=
20;attempt” to do that via the use of IfName, IfIndex, EntPhysicalNam=
e and EntPhysicalIndex (which are SNMP physical entities).  However yo=
u have logical entities that the current structure doesn’t
 permit you to define as the observation points.  Is that a correct in=
terpretation of the current yang for ipfix?  How can you refer to logi=
cal entities? (it seems the only place you could do this was to stick the l=
eaf-ref into the name but not a good yang
 practice).


 


Please advise.


 


Thanks.


 


Marta Seda


 


 






--_000_BY2PR0501MB17346D370676D56617BC67A49C2A0BY2PR0501MB1734_--


From nobody Sat Mar 11 05:14:03 2017
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3792D1294A4; Sat, 11 Mar 2017 05:14:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMLPtjIEfR0a; Sat, 11 Mar 2017 05:13:59 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68F912945B; Sat, 11 Mar 2017 05:13:58 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id E1449282F000; Sat, 11 Mar 2017 14:13:50 +0100 (CET)
To: Marta Seda , "ipfix@ietf.org" , "ie-doctors@ietf.org" 
References: 
From: Gerhard Muenz 
Message-ID: 
Date: Sat, 11 Mar 2017 14:13:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------5BA4A5D252CA0A1BAC9EA559"
Archived-At: 
Subject: Re: [IPFIX] RFC 6728: Observation Point ID definition
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Mar 2017 13:14:01 -0000

This is a multi-part message in MIME format.
--------------5BA4A5D252CA0A1BAC9EA559
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit


Hello Marta,

Observation Point is an IPFIX term defined in RFC5101 and then RFC7011 ( 
https://tools.ietf.org/html/rfc7011#page-8 ):

    Observation Point

       An Observation Point is a location in the network where packets
       can be observed.  Examples include a line to which a probe is
       attached; a shared medium, such as an Ethernet-based LAN; a single
       port of a router; or a set of interfaces (physical or logical) of
       a router.


The ObservationPoint class defined in RFC6728 ( 
https://tools.ietf.org/html/rfc6728#section-4.1 ) allows to identify 
such an Observation Point in a Monitoring Device.

It seems that you do not want to specify a point for observing packets, 
right? Then, the ObservationPoint class is not the right class for your 
use case.

You can define your own yang module or extend the existing one with a 
new class that allows to identify your source of statistics, whatever 
that shall be.

Regards,
Gerhard


On 04.03.2017 17:21, Marta Seda wrote:
>
> Hello,
>
> RFC 6728 defines the observation point as the “location for which 
> packets are observed”.  RFC 6727 page 4.1 shows this uml relationship:
>
> +-------------------------------+
>
>          | ObservationPoint              |
>
>        +-------------------------------+
>
>          | name                          |
>
>          | observationPointId {readOnly} |
>
>          | observationDomainId           | 0..*
>
>          | ifName[0..*]                  |-------------+
>
>          | ifIndex[0..*]                 |             | 0..*
>
>          | entPhysicalName[0..*]         |             V
>
>          | entPhysicalIndex[0..*]        |    +------------------+
>
>          | direction = "both"            |    | SelectionProcess |
>
> +-------------------------------+    +------------------+
>
> In RFC 6728, the observationpointid, ifname, ifindex,entphysicalname 
> and entphysicalindex are part of the observationpointparameters grouping.
>
> RFC 6728 has examples centered around the idea of creating a metering 
> process that samples packets and reports statistics over ipfix 
> (netflow-like statistics).
>
> There is yang models that configure statistic collection.   It seems 
> in that case (if you want to use ipfix to carry those statistics), 
> that the observation point could refer to those entities (leaf-ref) 
> that are already collecting statistics.  When I look at the RFC 6728 
> yang structure it seems there is an “attempt” to do that via the use 
> of IfName, IfIndex, EntPhysicalName and EntPhysicalIndex (which are 
> SNMP physical entities).  However you have logical entities that the 
> current structure doesn’t permit you to define as the observation 
> points.  Is that a correct interpretation of the current yang for 
> ipfix?  How can you refer to logical entities? (it seems the only 
> place you could do this was to stick the leaf-ref into the name but 
> not a good yang practice).
>
> Please advise.
>
> Thanks.
>
> Marta Seda
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------5BA4A5D252CA0A1BAC9EA559
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    Hello Marta,

    

    Observation Point is an IPFIX term defined in RFC5101 and then
    RFC7011 ( https://tools.ietf.org/html/rfc7011#page-8 ):

    

    
   Observation Point

      An Observation Point is a location in the network where packets
      can be observed.  Examples include a line to which a probe is
      attached; a shared medium, such as an Ethernet-based LAN; a single
      port of a router; or a set of interfaces (physical or logical) of
      a router.

    

    The ObservationPoint class defined in RFC6728 (
    https://tools.ietf.org/html/rfc6728#section-4.1 ) allows to identify
    such an Observation Point in a Monitoring Device.

    

    It seems that you do not want to specify a point for observing
    packets, right? Then, the ObservationPoint class is not the right
    class for your use case.

    

    You can define your own yang module or extend the existing one with
    a new class that allows to identify your source of statistics,
    whatever that shall be.

    

    Regards,

    Gerhard

    

    

    
On 04.03.2017 17:21, Marta Seda wrote:

    

    

      
      
      
      

        
Hello,

        
 

        
RFC 6728 defines the observation point as
          the “location for which packets are observed”.  RFC 6727 page
          4.1 shows this uml relationship:

        
 

        
        
            +-------------------------------+

        
         |
            ObservationPoint              |

        
 
                   +-------------------------------+

        
         |
            name                          |

        
         | observationPointId
            {readOnly} |

        
         |
            observationDomainId           | 0..*

        
         |
            ifName[0..*]                  |-------------+

        
         |
            ifIndex[0..*]                 |             | 0..*

        
         |
            entPhysicalName[0..*]         |             V

        
         |
            entPhysicalIndex[0..*]        |    +------------------+

        
         | direction =
            "both"            |    | SelectionProcess |

        
        
            +-------------------------------+    +------------------+

        
 

        
 

        
In RFC 6728, the observationpointid,
          ifname, ifindex,entphysicalname and entphysicalindex are part
          of the observationpointparameters grouping.

        
 

        
RFC 6728 has examples centered around the
          idea of creating a metering process that samples packets and
          reports statistics over ipfix (netflow-like statistics). 
          

        
 

        
There is yang models that configure
          statistic collection.   It seems in that case (if you want to
          use ipfix to carry those statistics), that the observation
          point could refer to those entities (leaf-ref) that are
          already collecting statistics.  When I look at the RFC 6728
          yang structure it seems there is an “attempt” to do that via
          the use of IfName, IfIndex, EntPhysicalName and
          EntPhysicalIndex (which are SNMP physical entities).  However
          you have logical entities that the current structure doesn’t
          permit you to define as the observation points.  Is that a
          correct interpretation of the current yang for ipfix?  How can
          you refer to logical entities? (it seems the only place you
          could do this was to stick the leaf-ref into the name but not
          a good yang practice).

        
 

        
Please advise.

        
 

        
Thanks.

        
 

        
Marta Seda

        
 

        
 

      

      

      

      

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


    

    

  


--------------5BA4A5D252CA0A1BAC9EA559--


From nobody Wed Mar 29 10:57:53 2017
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8418912025C; Wed, 29 Mar 2017 10:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.918
X-Spam-Level: 
X-Spam-Status: No, score=-6.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk2r2qeraedE; Wed, 29 Mar 2017 10:57:48 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EF51292F4; Wed, 29 Mar 2017 10:57:46 -0700 (PDT)
From: Abdelkader Lahmadi 
X-IronPort-AV: E=Sophos;i="5.36,242,1486422000";  d="asc'?scan'208,217";a="218516440"
Received: from 4ab54-4-88-163-251-98.fbx.proxad.net (HELO [192.168.0.14]) ([88.163.251.98]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 19:57:43 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_B0CE45B4-3532-40D4-AE6B-3832ADD28E8E"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
In-Reply-To: <6AA4BDC1-D371-4576-9C5D-BBC49391095B@netapp.com>
Date: Wed, 29 Mar 2017 19:57:45 +0200
Cc: PJ Aitken , "draft-irtf-nmrg-location-ipfix.authors@ietf.org" ,  "opsawg-chairs@ietf.org" , "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" , "Internet Research Steering Group (irsg@irtf.org)" , Rick Hofstede 
Message-Id: <7DBCA7BE-C819-4107-AC7A-A5CA08680B18@loria.fr>
References:  <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr>  <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr>  <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr> <6AA4BDC1-D371-4576-9C5D-BBC49391095B@netapp.com>
To: "Eggert, Lars" 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 17:57:52 -0000

--Apple-Mail=_B0CE45B4-3532-40D4-AE6B-3832ADD28E8E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3D344708-64BD-4A33-ABFA-5DC032B3F21C"


--Apple-Mail=_3D344708-64BD-4A33-ABFA-5DC032B3F21C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Dear Lars, and NMRG chairs,
How we can proceed now with the draft?

According to this: =
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/=
00/ =
, It seems that the draft is not in conflict with IETF work.
But, it seems that an IETF review and IESG approval are required for =
registering the location method tokens according to this:
=
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/=
 =


I suppose that we can now update the draft with the IANA recommendation =
and also the review provided IPFIX expert (Paul).
Thank you.
Best regards.
> On 03 Mar 2017, at 12:28, Eggert, Lars  wrote:
>=20
> On 2017-3-3, at 12:17, Abdelkader Lahmadi =
 wrote:
>> So, we work on a new text to resolve ALL the raised issues and send =
you a version.
>=20
> Hang on. Your RG chair should have explained how the process works.
>=20
> This IRTF document is now being reviewed (per RFC5742) by the IESG. =
That review is *not* the same review that happens for IETF documents. =
Specifically, the IESG can really only say one of these five things:
>=20
>>   1. The IESG has concluded that there is no conflict between this
>>      document and IETF work.
>>=20
>>   2. The IESG has concluded that this work is related to IETF work =
done
>>      in WG , but this relationship does not prevent publishing.
>>=20
>>   3. The IESG has concluded that publication could potentially =
disrupt
>>      the IETF work done in WG  and recommends not publishing the
>>      document at this time.
>>=20
>>   4. The IESG has concluded that this document violates IETF =
procedures
>>      for  and should therefore not be published without IETF =
review
>>      and IESG approval.
>>=20
>>   5. The IESG has concluded that this document extends an IETF =
protocol
>>      in a way that requires IETF review and should therefore not be
>>      published without IETF review and IESG approval.
>=20
>=20
> At the moment, you are getting individual comments from IPFIX experts =
as part of the IANA review process of the registry actions your document =
wants to make happen. Those are very valuable (thank you!), but before =
you make any changes to the document, please wait until an Area Director =
says that the issues raised are at a significance where they will ask =
for an IESG response other than #1 or #2 above.
>=20
> It sounds like this is likely going to be the case here, but please =
wait until the ADs have caught up on the discussion. And please wait =
with submitting a new revision until that happens as well.
>=20
> Lars
>=20
>=20
>>=20
>> Best,
>>> On 03 Mar 2017, at 12:07, PJ Aitken  wrote:
>>>=20
>>> Abdelkader, it was me who did the IE-doctors review. That's only =
concerned with the IANA request; it's not an IPFIX review of the =
document.
>>>=20
>>> P.
>>>=20
>>>=20
>>> On 03/03/17 11:01, Abdelkader Lahmadi wrote:
>>>> Hello,
>>>> We haven=E2=80=99t really get a "proper review" of the document by =
IPFIX experts. Recently, we had a discussion with IANA and they asked =
IE-doctors to make a review, since that we received some points to be =
fixed regarding the proposed IE. I can forward to you the other comments =
from IE-doctors that we have received by IANA.
>>>>=20
>>>> Thank you for your comments, Ok we will fix the raised issues in =
the document.
>>>> Best regards.
>>>>=20
>>>>=20
>>>>> On 03 Mar 2017, at 11:42, PJ Aitken  wrote:
>>>>>=20
>>>>> Authors, has this document been reviewed by any IPFIX experts?
>>>>>=20
>>>>> I see a request on November 23rd, but no reviews. So let me sign =
up for that.
>>>>>=20
>>>>>=20
>>>>> First, I took a quick look at the Figures in Appendix B:
>>>>>=20
>>>>> Figure 1: the Field Count should be 5, not 2.
>>>>>=20
>>>>> Figure 2: the size of the optional Padding field is wrong: the =
figure shows 9 bits rather than 8.
>>>>>=20
>>>>> Figure 4: the Length of 32 should be 28. The =
"geospatialLocationPosLat" Information Element isn't defined.
>>>>>=20
>>>>> Figure 5: the Field Count of 2 should be 3.
>>>>>=20
>>>>> Figure 7: The "geospatialLocationPostLng" and =
"geospatialLocationtLng" Information Elements aren't defined.
>>>>>=20
>>>>> Figure 9: The sizes of the "CivicValue" data fields are not shown =
correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it =
should contain 21. Therefore the Figure is misleading and difficult to =
understand; it is not a good example. Please redraw the figure =
correctly. Please mark the variable-lengths eg "vlen =3D 21".
>>>>>=20
>>>>> Figure 11:
>>>>>  The Set IDs (311, 312, 313) do not correspond to the Template IDs =
in Figure 10 (306, 307, 308).
>>>>>  Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 =
octets rather than the requisite 27. Without the repeated "Grand", the =
21 would be correct. Please write "vlen=3D21"
>>>>>  The "Civic location Attr length" of 25 seems wrong.
>>>>>=20
>>>>>=20
>>>>> This document is not ready for publication. Please post an updated =
version so I can check that all the IPFIX details are correct.
>>>>>=20
>>>>> Thanks,
>>>>> P.
>>>=20
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>=20
>=20


--Apple-Mail=_3D344708-64BD-4A33-ABFA-5DC032B3F21C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Dear Lars, and NMRG chairs,
How we can proceed =
now with the draft? 

According to this: https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-loca=
tion-ipfix/00/, It seems that the draft is not in conflict with IETF =
work. 
But, it seems that an IETF review and =
IESG approval are required for registering the location method tokens =
according to this: 
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-loca=
tion-ipfix/

I suppose that we can now update the draft with the IANA =
recommendation and also the review provided IPFIX expert =
(Paul).
Thank you.
Best =
regards.
On 03 Mar 2017, at 12:28, Eggert, Lars <lars@netapp.com> =
wrote:

On =
2017-3-3, at 12:17, Abdelkader Lahmadi <abdelkader.lahmadi@loria.fr> wrote:
So, we work on a new =
text to resolve ALL the raised issues and send you a version.

Hang on. Your RG chair should =
have explained how the process works.

This =
IRTF document is now being reviewed (per RFC5742) by the IESG. That =
review is *not* the same review that happens for IETF documents. =
Specifically, the IESG can really only say one of these five things:

 =
  1. The IESG has concluded that there is no conflict between =
this
      document and IETF =
work.

   2. The IESG has =
concluded that this work is related to IETF work done
 =
     in WG <X>, but this relationship =
does not prevent publishing.

 =
  3. The IESG has concluded that publication could potentially =
disrupt
      the IETF work done =
in WG <X> and recommends not publishing the
 =
     document at this time.

   4. The IESG has concluded that this document =
violates IETF procedures
 =
     for <Y> and should therefore not be =
published without IETF review
 =
     and IESG approval.

   5. The IESG has concluded that this document =
extends an IETF protocol
      in =
a way that requires IETF review and should therefore not be
=
      published without IETF review and IESG =
approval.


At =
the moment, you are getting individual comments from IPFIX experts as =
part of the IANA review process of the registry actions your document =
wants to make happen. Those are very valuable (thank you!), but before =
you make any changes to the document, please wait until an Area Director =
says that the issues raised are at a significance where they will ask =
for an IESG response other than #1 or #2 above.

It sounds like this is likely going to be the case here, but =
please wait until the ADs have caught up on the discussion. And please =
wait with submitting a new revision until that happens as well.

Lars



Best,
On 03 Mar 2017, at =
12:07, PJ Aitken <pjaitken@brocade.com> wrote:

Abdelkader, it was me who did the IE-doctors review. That's =
only concerned with the IANA request; it's not an IPFIX review of the =
document.

P.

On 03/03/17 11:01, Abdelkader Lahmadi wrote:
Hello,
We =
haven=E2=80=99t really get a "proper review" of the document by IPFIX =
experts. Recently, we had a discussion with IANA and they asked =
IE-doctors to make a review, since that we received some points to be =
fixed regarding the proposed IE. I can forward to you the other comments =
from IE-doctors that we have received by IANA.

Thank you for your comments, Ok we will fix the raised issues =
in the document.
Best regards.


On 03 Mar =
2017, at 11:42, PJ Aitken <pjaitken@brocade.com> wrote:

Authors, has this document been reviewed by any IPFIX =
experts?

I see a request on November 23rd, =
but no reviews. So let me sign up for that.


First, I took a quick look at the Figures in =
Appendix B:

Figure 1: the Field Count =
should be 5, not 2.

Figure 2: the size of =
the optional Padding field is wrong: the figure shows 9 bits rather than =
8.

Figure 4: the Length of 32 should be 28. =
The "geospatialLocationPosLat" Information Element isn't defined.

Figure 5: the Field Count of 2 should be 3.

Figure 7: The "geospatialLocationPostLng" and =
"geospatialLocationtLng" Information Elements aren't defined.

Figure 9: The sizes of the "CivicValue" data =
fields are not shown correctly. eg, "Inria Nancy-Grand Est" is depicted =
in 6 octets when it should contain 21. Therefore the Figure is =
misleading and difficult to understand; it is not a good example. Please =
redraw the figure correctly. Please mark the variable-lengths eg "vlen =3D=
 21".

Figure 11:
  The =
Set IDs (311, 312, 313) do not correspond to the Template IDs in Figure =
10 (306, 307, 308).
  Again, the "Inria Nancy-Grand =
Grand Est" field is depicted in 6 octets rather than the requisite 27. =
Without the repeated "Grand", the 21 would be correct. Please write =
"vlen=3D21"
  The "Civic location Attr length" of 25 =
seems wrong.


This document =
is not ready for publication. Please post an updated version so I can =
check that all the IPFIX details are correct.

Thanks,
P.

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



=

--Apple-Mail=_3D344708-64BD-4A33-ABFA-5DC032B3F21C--

--Apple-Mail=_B0CE45B4-3532-40D4-AE6B-3832ADD28E8E
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

iQIcBAEBCgAGBQJY2/WZAAoJEBX1Mi7AAzI6OAMQAKIBNmpuvtTjPasm/1BBeK0c
PIIDpErCCiDWsi3Uf4yVNO8gu7CKHXK2WvULl+S/IY9G9l6ZANg4lGbXRWwicqIJ
Y15ot9Ue7cu55ZcNvueEW6nIrH7iSYVMryIWTwh+tLaFG2QIZ74IynvpDTzBKW0e
fvSefVTIBkdWmEpNdHAsV72c1RezMj9awZtsw3plSWYKBcm/PwkGW9KhsK10ivS6
pD8TOtkGrCwFeAzihNGD44IeCgRMdvuJWCxFXheHnuWMlawTGBbbqvJO9BsOcFwe
QgSTiunY0m1f37xaYQlPn33HVJ+x7vdCtI592N+e3+zYgaUVfiqpHcEQVels+CCE
W9kZEUxpIjRmUvnkYsRMxFb5ZWB9cUxrO9uL2DwpSgBsrxq68TtF4XFIvPVnPCjt
DXVuHrJEN2ogUWiyFFA3OTH/phnCVzemDhmWyutFw780B7BnPOICDokUcWJ9rrJC
SUoWPgY0ewHrZrwuxrMLKfv0si57dJsxvosvWodRYa6zqlUZC+lMzXJKGIFHRgnU
1rYwTavqwtsBbL9HFqI8bIbBpDBQEy5gnlDhgzY2AA0nABXQ7DsXlKA/OcZvw4Aa
/bB+g3+d+nZTMC/Fd/3DlNTgw5sgnvNPeSF0oKGLGQQUDAn29G/0l40dhl5DNbhX
U9XtqVCjk5V3cNw3hic7
=uHr1
-----END PGP SIGNATURE-----

--Apple-Mail=_B0CE45B4-3532-40D4-AE6B-3832ADD28E8E--


From nobody Wed Mar 29 11:22:45 2017
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B4C126DDF; Wed, 29 Mar 2017 11:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com
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 kM-YhbZoGAPJ; Wed, 29 Mar 2017 11:22:40 -0700 (PDT)
Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC1B1267BB; Wed, 29 Mar 2017 11:22:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.36,242,1486454400";  d="asc'?scan'208";a="192607500"
Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx141-out.netapp.com with ESMTP; 29 Mar 2017 11:10:38 -0700
Received: from VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 11:21:20 -0700
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 29 Mar 2017 11:21:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6PoC5vOdVV1IsA7/pZrMWr1lLbky73s4vmLzOqjDZ5Q=; b=IanWz8CAxU+OKdDC8XxbAcMTiteadhzLqa7XGRky0PbPLESWnUqqq56q6UvK74xDeOKhVK3pUNb/Ju3RoBPzXkPcRANO+3bJvdHFFTNpEZWtMWNs5SakUJMkbWT6t+T0YRAA0to7rSZlT2ci0WxgncHKnTqhY0th2Zk89VJ+5Yw=
Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Wed, 29 Mar 2017 18:21:18 +0000
Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0991.021; Wed, 29 Mar 2017 18:21:18 +0000
From: "Eggert, Lars" 
To: Abdelkader Lahmadi 
CC: PJ Aitken , "draft-irtf-nmrg-location-ipfix.authors@ietf.org" , "opsawg-chairs@ietf.org" , "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" , "Internet Research Steering Group (irsg@irtf.org)" , Rick Hofstede 
Thread-Topic: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
Thread-Index: AQHSlA2rRN1dx6gTP0qxqcp8ZIxXXaGC9I4AgAAC9ACAAAL6AIApSViAgAAGkAA=
Date: Wed, 29 Mar 2017 18:21:18 +0000
Message-ID: 
References:  <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr>  <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr>  <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr> <6AA4BDC1-D371-4576-9C5D-BBC49391095B@netapp.com> <7DBCA7BE-C819-4107-AC7A-A5CA08680B18@loria.fr>
In-Reply-To: <7DBCA7BE-C819-4107-AC7A-A5CA08680B18@loria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3273)
authentication-results: loria.fr; dkim=none (message not signed) header.d=none;loria.fr; dmarc=none action=none header.from=netapp.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:67c:370:128:4520:3ece:ac25:8bd5]
x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:oEZx1SwAOsW4yU9W1kXRn4S2azsI2b4th6WK1JTED5nzkP4Lb6m/d+b9WxlpyjofuaCelCNWVR0mk1Le3IAZggb8de3bs+8MS2FfDXtRHv0Jpm11tUueDU258A80RD/3VLAspoy3VL5bnSOuCFSFZxyMNh1M1IoieQj62QH/T/zKU2zJ/VMKjL/9LH9WkCxzEF9Eu0Z/BIwLA2temo+aIj5VwSTE2q+EdfD9JBrCMCbGTsucGPXLDNq1O01RQij/KBUAT0l/0I3rENfL++bPmLeS+5iLi7Pk0peZXhR4tnyMRGTqB/4MpKefkd57tboUypC1Qqysfave/9MXPkB6UQ==
x-ms-office365-filtering-correlation-id: 53bee0f3-112e-4665-1174-08d476d064d4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN3PR0601MB1155; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; 
x-forefront-prvs: 0261CCEEDF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39850400002)(39410400002)(39840400002)(39400400002)(24454002)(45074003)(377424004)(50226002)(6916009)(2950100002)(33656002)(3280700002)(4326008)(25786009)(2906002)(122556002)(2900100001)(83716003)(82746002)(53546009)(57306001)(189998001)(3660700001)(7736002)(86362001)(305945005)(54906002)(99936001)(36756003)(230783001)(8676002)(93886004)(6306002)(81166006)(6512007)(8936002)(6486002)(6436002)(77096006)(6506006)(99286003)(345774005)(6246003)(102836003)(110136004)(229853002)(6116002)(76176999)(53936002)(50986999)(5660300001)(38730400002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_6D738C2D-8127-47C1-92E7-BA62D08ED4DD"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 18:21:18.1686 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155
X-OriginatorOrg: netapp.com
Archived-At: 
Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 18:22:44 -0000

--Apple-Mail=_6D738C2D-8127-47C1-92E7-BA62D08ED4DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

On 2017-3-29, at 12:57, Abdelkader Lahmadi  =
wrote:
> Dear Lars, and NMRG chairs,

Allison has taken over as chair, so this is a question for her. However:

> How we can proceed now with the draft?
>=20
> According to this: =
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/=
00/, It seems that the draft is not in conflict with IETF work.

The IESG has not yet concluded its review - that link at the moment =
captures the current status of individual ADs positions. They will send =
a formal response when their review has concluded.

> But, it seems that an IETF review and IESG approval are required for =
registering the location method tokens according to this:
> =
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/=


All IANA actions coming from the IETF require IESG approval. Typically, =
that approval is implicit in a review that results in a document being =
publishable.

> I suppose that we can now update the draft with the IANA =
recommendation and also the review provided IPFIX expert (Paul).

I'd wait until the IESG review has concluded.

Lars




> Thank you.
> Best regards.
>> On 03 Mar 2017, at 12:28, Eggert, Lars  wrote:
>>=20
>> On 2017-3-3, at 12:17, Abdelkader Lahmadi =
 wrote:
>>> So, we work on a new text to resolve ALL the raised issues and send =
you a version.
>>=20
>> Hang on. Your RG chair should have explained how the process works.
>>=20
>> This IRTF document is now being reviewed (per RFC5742) by the IESG. =
That review is *not* the same review that happens for IETF documents. =
Specifically, the IESG can really only say one of these five things:
>>=20
>>>   1. The IESG has concluded that there is no conflict between this
>>>      document and IETF work.
>>>=20
>>>   2. The IESG has concluded that this work is related to IETF work =
done
>>>      in WG , but this relationship does not prevent publishing.
>>>=20
>>>   3. The IESG has concluded that publication could potentially =
disrupt
>>>      the IETF work done in WG  and recommends not publishing the
>>>      document at this time.
>>>=20
>>>   4. The IESG has concluded that this document violates IETF =
procedures
>>>      for  and should therefore not be published without IETF =
review
>>>      and IESG approval.
>>>=20
>>>   5. The IESG has concluded that this document extends an IETF =
protocol
>>>      in a way that requires IETF review and should therefore not be
>>>      published without IETF review and IESG approval.
>>=20
>>=20
>> At the moment, you are getting individual comments from IPFIX experts =
as part of the IANA review process of the registry actions your document =
wants to make happen. Those are very valuable (thank you!), but before =
you make any changes to the document, please wait until an Area Director =
says that the issues raised are at a significance where they will ask =
for an IESG response other than #1 or #2 above.
>>=20
>> It sounds like this is likely going to be the case here, but please =
wait until the ADs have caught up on the discussion. And please wait =
with submitting a new revision until that happens as well.
>>=20
>> Lars
>>=20
>>=20
>>>=20
>>> Best,
>>>> On 03 Mar 2017, at 12:07, PJ Aitken  wrote:
>>>>=20
>>>> Abdelkader, it was me who did the IE-doctors review. That's only =
concerned with the IANA request; it's not an IPFIX review of the =
document.
>>>>=20
>>>> P.
>>>>=20
>>>>=20
>>>> On 03/03/17 11:01, Abdelkader Lahmadi wrote:
>>>>> Hello,
>>>>> We haven=E2=80=99t really get a "proper review" of the document by =
IPFIX experts. Recently, we had a discussion with IANA and they asked =
IE-doctors to make a review, since that we received some points to be =
fixed regarding the proposed IE. I can forward to you the other comments =
from IE-doctors that we have received by IANA.
>>>>>=20
>>>>> Thank you for your comments, Ok we will fix the raised issues in =
the document.
>>>>> Best regards.
>>>>>=20
>>>>>=20
>>>>>> On 03 Mar 2017, at 11:42, PJ Aitken  wrote:
>>>>>>=20
>>>>>> Authors, has this document been reviewed by any IPFIX experts?
>>>>>>=20
>>>>>> I see a request on November 23rd, but no reviews. So let me sign =
up for that.
>>>>>>=20
>>>>>>=20
>>>>>> First, I took a quick look at the Figures in Appendix B:
>>>>>>=20
>>>>>> Figure 1: the Field Count should be 5, not 2.
>>>>>>=20
>>>>>> Figure 2: the size of the optional Padding field is wrong: the =
figure shows 9 bits rather than 8.
>>>>>>=20
>>>>>> Figure 4: the Length of 32 should be 28. The =
"geospatialLocationPosLat" Information Element isn't defined.
>>>>>>=20
>>>>>> Figure 5: the Field Count of 2 should be 3.
>>>>>>=20
>>>>>> Figure 7: The "geospatialLocationPostLng" and =
"geospatialLocationtLng" Information Elements aren't defined.
>>>>>>=20
>>>>>> Figure 9: The sizes of the "CivicValue" data fields are not shown =
correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets when it =
should contain 21. Therefore the Figure is misleading and difficult to =
understand; it is not a good example. Please redraw the figure =
correctly. Please mark the variable-lengths eg "vlen =3D 21".
>>>>>>=20
>>>>>> Figure 11:
>>>>>>  The Set IDs (311, 312, 313) do not correspond to the Template =
IDs in Figure 10 (306, 307, 308).
>>>>>>  Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 =
octets rather than the requisite 27. Without the repeated "Grand", the =
21 would be correct. Please write "vlen=3D21"
>>>>>>  The "Civic location Attr length" of 25 seems wrong.
>>>>>>=20
>>>>>>=20
>>>>>> This document is not ready for publication. Please post an =
updated version so I can check that all the IPFIX details are correct.
>>>>>>=20
>>>>>> Thanks,
>>>>>> P.
>>>>=20
>>>> _______________________________________________
>>>> IPFIX mailing list
>>>> IPFIX@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>=20
>>=20
>=20


--Apple-Mail=_6D738C2D-8127-47C1-92E7-BA62D08ED4DD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY2/saAAoJEFS1wwm/cMFX10cP/jiUj2AnkOradF2h9Q1KX/hb
5GrB6AXGgV4DvtmhL2bK0vJC/Eok0cxDHaEa1QpLNeQL3pUEL4XxvpZPeBkiOK5g
GSzBefTBeFkg6bos+6CY4bGA2uovDkzssZAshFCnNK6TTlRpqNx6pg1Y0I6eNdHW
+4GzjLha3w7YOzwa8K2MHcZrKbihSANvDU8+WEw9qBJOj8l3ol3XYUzIvZpU+D2i
rSBgiOYt/QUfQYSXYhBy+wX6+EUwj4Cwprxc8cWsSex8FR5ztDChziHPWS0JgBlU
pBy6Fn2oCBCCLjnmVA/QAnXdWC+cZjRf9kQVH4L9XupriXuW/bbDKTiu2CAdbVYT
1Rl+Fwh4xpQ3w1VzpF550BpYj3NQ2PCdmHGLpgQb12ymrOHoh+Wsvq+uSWUFO4JL
eW/lVXkqyNvkkRIelSb4Ujm6wtvdDfyOSV5p3xSdtUDitcGHziDXGyJDAsP2kPWl
gUJMxYVMs2LyrcROIGjp85CL4woBf79ey5VETKgH5pwk3AOAZmTyar+w6VvMhUhj
gT6/M8ppQ/sXyj7UiCI0lspkhVAD0k5SBHjABsfghb4qHUMw4fk5mB0Mt1+jJPhn
IAUKWTJibVsWGDAZfg4YotuG3/fuu9bDE/iMEiN17cvy4NQxDszQS37ssSEqtL5w
lX8OUzRGKLA1UE0Uq01h
=Ct6/
-----END PGP SIGNATURE-----

--Apple-Mail=_6D738C2D-8127-47C1-92E7-BA62D08ED4DD--


From nobody Wed Mar 29 11:27:00 2017
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB4F1294AA; Wed, 29 Mar 2017 11:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.919
X-Spam-Level: 
X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULDU_qfFwUfk; Wed, 29 Mar 2017 11:26:54 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6441129455; Wed, 29 Mar 2017 11:26:47 -0700 (PDT)
From: Abdelkader Lahmadi 
X-IronPort-AV: E=Sophos;i="5.36,242,1486422000";  d="asc'?scan'208";a="218518650"
Received: from 4ab54-4-88-163-251-98.fbx.proxad.net (HELO [192.168.0.14]) ([88.163.251.98]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 20:26:45 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4BE8CCBD-9294-4C1E-895E-1AA77C048DA9"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
In-Reply-To: 
Date: Wed, 29 Mar 2017 20:26:46 +0200
Cc: PJ Aitken , "draft-irtf-nmrg-location-ipfix.authors@ietf.org" ,  "opsawg-chairs@ietf.org" , "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" , "Internet Research Steering Group (irsg@irtf.org)" , Rick Hofstede 
Message-Id: <4589928D-6C85-4392-9774-D149AB8A1997@loria.fr>
References:  <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr>  <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr>  <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr> <6AA4BDC1-D371-4576-9C5D-BBC49391095B@netapp.com> <7DBCA7BE-C819-4107-AC7A-A5CA08680B18@loria.fr> 
To: "Eggert, Lars" 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 18:26:58 -0000

--Apple-Mail=_4BE8CCBD-9294-4C1E-895E-1AA77C048DA9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thank you for the answers.
Best,

> On 29 Mar 2017, at 20:21, Eggert, Lars  wrote:
>=20
> Hi,
>=20
> On 2017-3-29, at 12:57, Abdelkader Lahmadi =
 wrote:
>> Dear Lars, and NMRG chairs,
>=20
> Allison has taken over as chair, so this is a question for her. =
However:
>=20
>> How we can proceed now with the draft?
>>=20
>> According to this: =
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/=
00/, It seems that the draft is not in conflict with IETF work.
>=20
> The IESG has not yet concluded its review - that link at the moment =
captures the current status of individual ADs positions. They will send =
a formal response when their review has concluded.
>=20
>> But, it seems that an IETF review and IESG approval are required for =
registering the location method tokens according to this:
>> =
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/=

>=20
> All IANA actions coming from the IETF require IESG approval. =
Typically, that approval is implicit in a review that results in a =
document being publishable.
>=20
>> I suppose that we can now update the draft with the IANA =
recommendation and also the review provided IPFIX expert (Paul).
>=20
> I'd wait until the IESG review has concluded.
>=20
> Lars
>=20
>=20
>=20
>=20
>> Thank you.
>> Best regards.
>>> On 03 Mar 2017, at 12:28, Eggert, Lars  wrote:
>>>=20
>>> On 2017-3-3, at 12:17, Abdelkader Lahmadi =
 wrote:
>>>> So, we work on a new text to resolve ALL the raised issues and send =
you a version.
>>>=20
>>> Hang on. Your RG chair should have explained how the process works.
>>>=20
>>> This IRTF document is now being reviewed (per RFC5742) by the IESG. =
That review is *not* the same review that happens for IETF documents. =
Specifically, the IESG can really only say one of these five things:
>>>=20
>>>>  1. The IESG has concluded that there is no conflict between this
>>>>     document and IETF work.
>>>>=20
>>>>  2. The IESG has concluded that this work is related to IETF work =
done
>>>>     in WG , but this relationship does not prevent publishing.
>>>>=20
>>>>  3. The IESG has concluded that publication could potentially =
disrupt
>>>>     the IETF work done in WG  and recommends not publishing the
>>>>     document at this time.
>>>>=20
>>>>  4. The IESG has concluded that this document violates IETF =
procedures
>>>>     for  and should therefore not be published without IETF =
review
>>>>     and IESG approval.
>>>>=20
>>>>  5. The IESG has concluded that this document extends an IETF =
protocol
>>>>     in a way that requires IETF review and should therefore not be
>>>>     published without IETF review and IESG approval.
>>>=20
>>>=20
>>> At the moment, you are getting individual comments from IPFIX =
experts as part of the IANA review process of the registry actions your =
document wants to make happen. Those are very valuable (thank you!), but =
before you make any changes to the document, please wait until an Area =
Director says that the issues raised are at a significance where they =
will ask for an IESG response other than #1 or #2 above.
>>>=20
>>> It sounds like this is likely going to be the case here, but please =
wait until the ADs have caught up on the discussion. And please wait =
with submitting a new revision until that happens as well.
>>>=20
>>> Lars
>>>=20
>>>=20
>>>>=20
>>>> Best,
>>>>> On 03 Mar 2017, at 12:07, PJ Aitken  wrote:
>>>>>=20
>>>>> Abdelkader, it was me who did the IE-doctors review. That's only =
concerned with the IANA request; it's not an IPFIX review of the =
document.
>>>>>=20
>>>>> P.
>>>>>=20
>>>>>=20
>>>>> On 03/03/17 11:01, Abdelkader Lahmadi wrote:
>>>>>> Hello,
>>>>>> We haven=E2=80=99t really get a "proper review" of the document =
by IPFIX experts. Recently, we had a discussion with IANA and they asked =
IE-doctors to make a review, since that we received some points to be =
fixed regarding the proposed IE. I can forward to you the other comments =
from IE-doctors that we have received by IANA.
>>>>>>=20
>>>>>> Thank you for your comments, Ok we will fix the raised issues in =
the document.
>>>>>> Best regards.
>>>>>>=20
>>>>>>=20
>>>>>>> On 03 Mar 2017, at 11:42, PJ Aitken  =
wrote:
>>>>>>>=20
>>>>>>> Authors, has this document been reviewed by any IPFIX experts?
>>>>>>>=20
>>>>>>> I see a request on November 23rd, but no reviews. So let me sign =
up for that.
>>>>>>>=20
>>>>>>>=20
>>>>>>> First, I took a quick look at the Figures in Appendix B:
>>>>>>>=20
>>>>>>> Figure 1: the Field Count should be 5, not 2.
>>>>>>>=20
>>>>>>> Figure 2: the size of the optional Padding field is wrong: the =
figure shows 9 bits rather than 8.
>>>>>>>=20
>>>>>>> Figure 4: the Length of 32 should be 28. The =
"geospatialLocationPosLat" Information Element isn't defined.
>>>>>>>=20
>>>>>>> Figure 5: the Field Count of 2 should be 3.
>>>>>>>=20
>>>>>>> Figure 7: The "geospatialLocationPostLng" and =
"geospatialLocationtLng" Information Elements aren't defined.
>>>>>>>=20
>>>>>>> Figure 9: The sizes of the "CivicValue" data fields are not =
shown correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets =
when it should contain 21. Therefore the Figure is misleading and =
difficult to understand; it is not a good example. Please redraw the =
figure correctly. Please mark the variable-lengths eg "vlen =3D 21".
>>>>>>>=20
>>>>>>> Figure 11:
>>>>>>> The Set IDs (311, 312, 313) do not correspond to the Template =
IDs in Figure 10 (306, 307, 308).
>>>>>>> Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 =
octets rather than the requisite 27. Without the repeated "Grand", the =
21 would be correct. Please write "vlen=3D21"
>>>>>>> The "Civic location Attr length" of 25 seems wrong.
>>>>>>>=20
>>>>>>>=20
>>>>>>> This document is not ready for publication. Please post an =
updated version so I can check that all the IPFIX details are correct.
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> P.
>>>>>=20
>>>>> _______________________________________________
>>>>> IPFIX mailing list
>>>>> IPFIX@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_4BE8CCBD-9294-4C1E-895E-1AA77C048DA9
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

iQIcBAEBCgAGBQJY2/xmAAoJEBX1Mi7AAzI6OdAP/iwVv0yASCYXwo0+vJxpbCcy
CEou8OO7z1TJ3gO5Rb2sPqPSmWPWXfjdC+RNTJbsnpnGRBtA2tHkdrbqFIH7snYD
cHP/8m9NztsS+RWlKQbbJl58Hl+VPmBCSEb1mvBvWMjRa9cZSBt4Ed9W0k90G8/V
dv7tXGfZ4Fq/D4YHvjJDViHJUbpJe0t9pr2n2AtFWhBJ/zWMl1B0k8ouz3Y2oqYX
se6oDEwhdqG8pxhUz1NeI1iiL9tq/1Z3iFwnI9khhWFrOj8CqZV+OsXOVedZSsV1
CAC6h9ev8D6+zCH+EG+R6uuglIeCQKFO1LbGTj5cresYEo4IxRv9DTCkaOm6vKLh
B7EcL6MTFFHnvwbcOkqB7WwCZacBCbp9xIhJ0AiesMoPQFkoEjAPp5n9lCYmEJHM
UFBfnY0QzoTrRLQ0gyjfwaZljlkkv6Fprkx6b1X3EeDYyTHWDFj+Aq6N4jg5YEBB
ZCPXOnjeK9R6JPCak6sqbkMLzVE5uQ/4MXOyCNp6fNfv39zHQinaiQNUt9RJPTWm
8SchMasazZYrGrddGuHxIyMCHMuskRWugxAyt+38EOqumMPM1RoblZ4GrUDYpER0
AOFddmc3p1JtOAoENMBa12N5It1GGSMhjGmFxOSKUxqJ+c/yqWTGINgFpyR37e1b
MeNXJZhW2xgWlfqiMFkP
=cN5o
-----END PGP SIGNATURE-----

--Apple-Mail=_4BE8CCBD-9294-4C1E-895E-1AA77C048DA9--


From nobody Wed Mar 29 11:29:36 2017
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEB9126B72; Wed, 29 Mar 2017 11:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com
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 0Cb7I_8ZUE2i; Wed, 29 Mar 2017 11:29:30 -0700 (PDT)
Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3E712025C; Wed, 29 Mar 2017 11:29:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.36,242,1486454400";  d="asc'?scan'208";a="179701701"
Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 29 Mar 2017 11:17:05 -0700
Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 11:28:28 -0700
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 29 Mar 2017 11:28:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4evFL2l7xH2riW7aSeb4SCLwIpL501QT7vl4DAgLTYw=; b=C5Irl68Zih92FHo66OqmvZS8EQXK4PRNvU9FY3qjGqgsvXuxypkUhYdDKNB8oolNj8QDpuTd17cRbGOXoTN6xvWml+PzbECcnqLCEyktad5SA5mDTHcUfryls58bpDSBWtTQDVrVZGk4mX0v31Dk2hOg0pcT/SFijMFzm7i6Jr4=
Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Wed, 29 Mar 2017 18:28:27 +0000
Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0991.021; Wed, 29 Mar 2017 18:28:27 +0000
From: "Eggert, Lars" 
To: Abdelkader Lahmadi 
CC: "IPFIX@ietf.org" , "nmrg-chairs@ietf.org" , "Internet Research Steering Group (irsg@irtf.org)" , "draft-irtf-nmrg-location-ipfix.authors@ietf.org" , "opsawg-chairs@ietf.org" , PJ Aitken , Rick Hofstede 
Thread-Topic: [irsg] [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
Thread-Index: AQHSlA2rRN1dx6gTP0qxqcp8ZIxXXaGC9I4AgAAC9ACAAAL6AIApSViAgAAGkACAAAH/gA==
Date: Wed, 29 Mar 2017 18:28:27 +0000
Message-ID: <4ECEFCC5-683E-4F53-AF42-FFDC7A48FE05@netapp.com>
References:  <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr>  <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr>  <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr> <6AA4BDC1-D371-4576-9C5D-BBC49391095B@netapp.com> <7DBCA7BE-C819-4107-AC7A-A5CA08680B18@loria.fr> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3273)
authentication-results: loria.fr; dkim=none (message not signed) header.d=none;loria.fr; dmarc=none action=none header.from=netapp.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:67c:370:128:4520:3ece:ac25:8bd5]
x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:sEr7IwonCtFG/TnYteM7lOVKPi7zgA8eXcfcw3izqpHGgFrUb+adnaifFqfyFygvV+bMB2mrypNHIxaRm+9aUCdM8Jduu8l25SFvyCRTDINYQjga18JdNl3nGyTQZ7NS4xxYlXdt+uhrvIYlckE1QrJtc0EPJuRqew+yyurI+sSwZDl75GQuUjX3Cj/izsl7Yba1B++9g1YN5s0VrcZmi5A/hhH3HZjw5CGYr5i4vPqFfujNNAOPkcrLvBqwQC6Oad8lpUlNcrivPMP6StuHUPw83bXj0ThkIf051zXdqAthVZsjzVBHsEThYui61+Cf4u03X4CJVxe9FN5Wf+aaCQ==
x-ms-office365-filtering-correlation-id: 57a86cd0-8e66-4874-fc29-08d476d164c2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN3PR0601MB1155; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(20161123562025)(6072148); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; 
x-forefront-prvs: 0261CCEEDF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39840400002)(39410400002)(39450400003)(39850400002)(45074003)(24454002)(377424004)(6306002)(8936002)(6512007)(81166006)(345774005)(99286003)(6436002)(6486002)(6506006)(77096006)(99936001)(54906002)(36756003)(8676002)(93886004)(230783001)(5660300001)(53936002)(50986999)(38730400002)(229853002)(6116002)(110136004)(6246003)(102836003)(76176999)(25786009)(3280700002)(4326008)(2900100001)(2906002)(122556002)(50226002)(2950100002)(6916009)(33656002)(305945005)(86362001)(7736002)(82746002)(83716003)(3660700001)(57306001)(53546009)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_57B32BB9-5C34-454C-B509-7806F5CC2CA7"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 18:28:27.5013 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155
X-OriginatorOrg: netapp.com
Archived-At: 
Subject: Re: [IPFIX] [irsg] Review of draft-irtf-nmrg-location-ipfix-07.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 18:29:34 -0000

--Apple-Mail=_57B32BB9-5C34-454C-B509-7806F5CC2CA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Correction: My spy on the IESG informs me that you linked to an outdated =
version of the review; the current one being =
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/=


The current review *does* call out a problem with the draft, but has not =
concluded yet.

Lars


> On 2017-3-29, at 13:21, Eggert, Lars  wrote:
>=20
> Hi,
>=20
> On 2017-3-29, at 12:57, Abdelkader Lahmadi =
 wrote:
>> Dear Lars, and NMRG chairs,
>=20
> Allison has taken over as chair, so this is a question for her. =
However:
>=20
>> How we can proceed now with the draft?
>>=20
>> According to this: =
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/=
00/, It seems that the draft is not in conflict with IETF work.
>=20
> The IESG has not yet concluded its review - that link at the moment =
captures the current status of individual ADs positions. They will send =
a formal response when their review has concluded.
>=20
>> But, it seems that an IETF review and IESG approval are required for =
registering the location method tokens according to this:
>> =
https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/=

>=20
> All IANA actions coming from the IETF require IESG approval. =
Typically, that approval is implicit in a review that results in a =
document being publishable.
>=20
>> I suppose that we can now update the draft with the IANA =
recommendation and also the review provided IPFIX expert (Paul).
>=20
> I'd wait until the IESG review has concluded.
>=20
> Lars
>=20
>=20
>=20
>=20
>> Thank you.
>> Best regards.
>>> On 03 Mar 2017, at 12:28, Eggert, Lars  wrote:
>>>=20
>>> On 2017-3-3, at 12:17, Abdelkader Lahmadi =
 wrote:
>>>> So, we work on a new text to resolve ALL the raised issues and send =
you a version.
>>>=20
>>> Hang on. Your RG chair should have explained how the process works.
>>>=20
>>> This IRTF document is now being reviewed (per RFC5742) by the IESG. =
That review is *not* the same review that happens for IETF documents. =
Specifically, the IESG can really only say one of these five things:
>>>=20
>>>>  1. The IESG has concluded that there is no conflict between this
>>>>     document and IETF work.
>>>>=20
>>>>  2. The IESG has concluded that this work is related to IETF work =
done
>>>>     in WG , but this relationship does not prevent publishing.
>>>>=20
>>>>  3. The IESG has concluded that publication could potentially =
disrupt
>>>>     the IETF work done in WG  and recommends not publishing the
>>>>     document at this time.
>>>>=20
>>>>  4. The IESG has concluded that this document violates IETF =
procedures
>>>>     for  and should therefore not be published without IETF =
review
>>>>     and IESG approval.
>>>>=20
>>>>  5. The IESG has concluded that this document extends an IETF =
protocol
>>>>     in a way that requires IETF review and should therefore not be
>>>>     published without IETF review and IESG approval.
>>>=20
>>>=20
>>> At the moment, you are getting individual comments from IPFIX =
experts as part of the IANA review process of the registry actions your =
document wants to make happen. Those are very valuable (thank you!), but =
before you make any changes to the document, please wait until an Area =
Director says that the issues raised are at a significance where they =
will ask for an IESG response other than #1 or #2 above.
>>>=20
>>> It sounds like this is likely going to be the case here, but please =
wait until the ADs have caught up on the discussion. And please wait =
with submitting a new revision until that happens as well.
>>>=20
>>> Lars
>>>=20
>>>=20
>>>>=20
>>>> Best,
>>>>> On 03 Mar 2017, at 12:07, PJ Aitken  wrote:
>>>>>=20
>>>>> Abdelkader, it was me who did the IE-doctors review. That's only =
concerned with the IANA request; it's not an IPFIX review of the =
document.
>>>>>=20
>>>>> P.
>>>>>=20
>>>>>=20
>>>>> On 03/03/17 11:01, Abdelkader Lahmadi wrote:
>>>>>> Hello,
>>>>>> We haven=E2=80=99t really get a "proper review" of the document =
by IPFIX experts. Recently, we had a discussion with IANA and they asked =
IE-doctors to make a review, since that we received some points to be =
fixed regarding the proposed IE. I can forward to you the other comments =
from IE-doctors that we have received by IANA.
>>>>>>=20
>>>>>> Thank you for your comments, Ok we will fix the raised issues in =
the document.
>>>>>> Best regards.
>>>>>>=20
>>>>>>=20
>>>>>>> On 03 Mar 2017, at 11:42, PJ Aitken  =
wrote:
>>>>>>>=20
>>>>>>> Authors, has this document been reviewed by any IPFIX experts?
>>>>>>>=20
>>>>>>> I see a request on November 23rd, but no reviews. So let me sign =
up for that.
>>>>>>>=20
>>>>>>>=20
>>>>>>> First, I took a quick look at the Figures in Appendix B:
>>>>>>>=20
>>>>>>> Figure 1: the Field Count should be 5, not 2.
>>>>>>>=20
>>>>>>> Figure 2: the size of the optional Padding field is wrong: the =
figure shows 9 bits rather than 8.
>>>>>>>=20
>>>>>>> Figure 4: the Length of 32 should be 28. The =
"geospatialLocationPosLat" Information Element isn't defined.
>>>>>>>=20
>>>>>>> Figure 5: the Field Count of 2 should be 3.
>>>>>>>=20
>>>>>>> Figure 7: The "geospatialLocationPostLng" and =
"geospatialLocationtLng" Information Elements aren't defined.
>>>>>>>=20
>>>>>>> Figure 9: The sizes of the "CivicValue" data fields are not =
shown correctly. eg, "Inria Nancy-Grand Est" is depicted in 6 octets =
when it should contain 21. Therefore the Figure is misleading and =
difficult to understand; it is not a good example. Please redraw the =
figure correctly. Please mark the variable-lengths eg "vlen =3D 21".
>>>>>>>=20
>>>>>>> Figure 11:
>>>>>>> The Set IDs (311, 312, 313) do not correspond to the Template =
IDs in Figure 10 (306, 307, 308).
>>>>>>> Again, the "Inria Nancy-Grand Grand Est" field is depicted in 6 =
octets rather than the requisite 27. Without the repeated "Grand", the =
21 would be correct. Please write "vlen=3D21"
>>>>>>> The "Civic location Attr length" of 25 seems wrong.
>>>>>>>=20
>>>>>>>=20
>>>>>>> This document is not ready for publication. Please post an =
updated version so I can check that all the IPFIX details are correct.
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> P.
>>>>>=20
>>>>> _______________________________________________
>>>>> IPFIX mailing list
>>>>> IPFIX@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_57B32BB9-5C34-454C-B509-7806F5CC2CA7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY2/zHAAoJEFS1wwm/cMFXnucP+QFNu40efZ5GwEzU4Lnii+Bv
8wefsAd91/M5PB83cKYTIvp1mv87VemLQujegSqhHxBzU3a20Z5iini6cu/ViWRc
/nlvecf9j6uv7it5T3yRiEsuyJ/oV8wC63owMVNpSx+VPqa0+Gf2buo4C0ECARiG
ngIdNQB8ukyMdHZhyeVpJGjnjxrjoppVCYeM4kfBXVQKLHsxyd4EH30lt5gMMNSf
Fa+AobQTwsB2VhvmakW/ZSJRbNz5NvAwrDzSQzZBtpDUmdmEIQlCL5qOZVWvIifm
ILl2oFTJzmlbt4azH9YBVGK+0M5Qe9qhG/j20oY+L85aKtjmnBZkUvBN47rSgg01
w3fuIhdviuH5Ts6zi0+3Bp1VkPR0s3XzG0jtIB1UFpdCL0J9P2zAzSazwddEyfk+
gEA5iwwgj7LBZiHUHnkSRWq+CJYY4JX0dFF46Upg+1H5pt4TWgDUo8Tve+cgSP/H
oJlc2bYiLr5aLcL8XCiNUs+kJrpKf2MXQV+bCe4mq9kwQEnVyjUjr6l+DFVm5L4q
gn6kVVKKs11xMd6yAdoZS49EJy6GRjuj0XDgerts7hB0hsjZva+IgxNHMsoDZjqO
DyNa9WCiTNNY21+7SkWeMYl414/HABNEV19b6tpwVntbIIQnVL8+/G+MDarYKAlk
JGLs41ohz/ocG7XdV93u
=zzgJ
-----END PGP SIGNATURE-----

--Apple-Mail=_57B32BB9-5C34-454C-B509-7806F5CC2CA7--


From nobody Thu Mar 30 05:46:10 2017
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6032C1296AA for ; Thu, 30 Mar 2017 05:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level: 
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK_4sz1zp0gZ for ; Thu, 30 Mar 2017 05:46:06 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5956129698 for ; Thu, 30 Mar 2017 05:46:06 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 41C72B81373; Thu, 30 Mar 2017 05:45:55 -0700 (PDT)
To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: pjaitken@brocade.com, ipfix@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170330124555.41C72B81373@rfc-editor.org>
Date: Thu, 30 Mar 2017 05:45:55 -0700 (PDT)
Archived-At: 
Subject: [IPFIX] [Technical Errata Reported] RFC5102 (4984)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 12:46:08 -0000

The following errata report has been submitted for RFC5102,
"Information Model for IP Flow Information Export".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=4984

--------------------------------------
Type: Technical
Reported by: Paul Aitken 

Section: 5.2.10, appA

Original Text
-------------
Each bit represents an Information Element in the Data Record 
with the n-th bit
representing the n-th Information Element.

Corrected Text
--------------
Each bit represents an Information Element in the Data Record,
with the n-th least significant bit
representing the n-th Information Element.

Notes
-----
A misunderstand arose as to whether bits were assigned in host order or network order - so clarify that the bits are assigned from the least significant to the most significant, ie right-to-left rather than left-to-right.

Moreover, this clarification applies to IANA's IPFIX registry.

NB RFC 8038 re-uses this definition for mibIndexIndicator. Consistency between the definitions is desirable.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5102 (draft-ietf-ipfix-info-15)
--------------------------------------
Title               : Information Model for IP Flow Information Export
Publication Date    : January 2008
Author(s)           : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG