Re: [IPFIX] [irsg] Review of draft-irtf-nmrg-location-ipfix-07.txt
"Eggert, Lars" <[email protected]> Wed, 29 Mar 2017 18:28:27 +0000
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
--===============7150596840179700624== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_57B32BB9-5C34-454C-B509-7806F5CC2CA7"; protocol="application/pgp-signature"; micalg=pgp-sha512 --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 <[email protected]> wrote: >=20 > Hi, >=20 > On 2017-3-29, at 12:57, Abdelkader Lahmadi = <[email protected]> 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 <[email protected]> wrote: >>>=20 >>> On 2017-3-3, at 12:17, Abdelkader Lahmadi = <[email protected]> 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 <X>, but this relationship does not prevent publishing. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=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 <[email protected]> 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 <[email protected]> = 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 >>>>> [email protected] >>>>> 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-- --===============7150596840179700624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix --===============7150596840179700624==--