Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt

Abdelkader Lahmadi <abdelkader.lahmadi@loria.fr> Wed, 29 March 2017 18:26 UTC

Return-Path: <abdelkader.lahmadi@loria.fr>
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 <abdelkader.lahmadi@loria.fr>
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: <FEF04314-8E1D-4026-BFCF-41FDB56F4A40@netapp.com>
Date: Wed, 29 Mar 2017 20:26:46 +0200
Cc: PJ Aitken <pjaitken@brocade.com>, "draft-irtf-nmrg-location-ipfix.authors@ietf.org" <draft-irtf-nmrg-location-ipfix.authors@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "IPFIX@ietf.org" <IPFIX@ietf.org>, "nmrg-chairs@ietf.org" <nmrg-chairs@ietf.org>, "Internet Research Steering Group (irsg@irtf.org)" <irsg@irtf.org>, Rick Hofstede <mail@rickhofstede.nl>
Message-Id: <4589928D-6C85-4392-9774-D149AB8A1997@loria.fr>
References: <BBA82579FD347748BEADC4C445EA0F21A2260FE9@NKGEML515-MBX.china.huawei.com> <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr> <cbc29c8a-5e11-7918-0afe-dfebafe0cd2c@gmail.com> <808e677f-f0ed-37de-2084-9f2074359658@brocade.com> <9F2B4045-D838-4D94-8B55-1599879537E2@loria.fr> <c056c266-5206-e87c-3535-d765e94b58ed@brocade.com> <24A6EB4E-2AED-4A31-A066-8D6EDB8E7C73@loria.fr> <6AA4BDC1-D371-4576-9C5D-BBC49391095B@netapp.com> <7DBCA7BE-C819-4107-AC7A-A5CA08680B18@loria.fr> <FEF04314-8E1D-4026-BFCF-41FDB56F4A40@netapp.com>
To: "Eggert, Lars" <lars@netapp.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/rZ-kYUZoxvoy4zT3VeJVjpupJTg>
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 <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2017 18:26:58 -0000

Thank you for the answers.
Best,

> On 29 Mar 2017, at 20:21, Eggert, Lars <lars@netapp.com>; wrote:
> 
> Hi,
> 
> On 2017-3-29, at 12:57, Abdelkader Lahmadi <abdelkader.lahmadi@loria.fr>; 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?
>> 
>> 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 <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’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
>>>> 
>>> 
>> 
>