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