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