IETF conflict review for draft-irtf-nmrg-location-ipfix
conflict-review-irtf-nmrg-location-ipfix-02
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-10-03
|
02 | Amy Vezza | The following approval message was sent From: The IESG To: irsg@irtf.org, Internet Research Steering Group , draft-irtf-nmrg-location-ipfix@ietf.org, … The following approval message was sent From: The IESG To: irsg@irtf.org, Internet Research Steering Group , draft-irtf-nmrg-location-ipfix@ietf.org, irtf-chair@irtf.org, nmrg-chairs@ietf.org Cc: IETF-Announce , The IESG , iana@iana.org Subject: Results of IETF-conflict review for draft-irtf-nmrg-location-ipfix-07 The IESG has completed a review of draft-irtf-nmrg-location-ipfix-07 consistent with RFC5742. The IESG recommends that 'Extending IP Flow-Based Network Monitoring with Location Information' NOT be published as an Informational RFC. The IESG has concluded that this document violates IETF procedures for establishment and modification of registries by updating RFC 4119 and the location method tokens registry and should therefore not be published without IETF review and IESG approval. The location method tokens registry was established by a standards track IETF consensus document, and should therefore not be modified in the manner described without IETF review and IESG approval, additional tokens if required are allocated allocated on a first come first serve basis and may of course be assigned. Respecting the request for IPFIX Information Elements. The IPFIX information elements registry requires only expert review and also does not necessitate IETF review or approval. The IESG would also like the IRTF to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-location-ipfix/ A URL of the reviewed Internet Draft is: https://datatracker.ietf.org/doc/draft-irtf-nmrg-location-ipfix/ The process for such documents is described in RFC 5743 Thank you, The IESG Secretary |
2017-10-03
|
02 | Amy Vezza | IESG has approved the conflict review response |
2017-10-03
|
02 | Amy Vezza | Closed "Approve" ballot |
2017-10-03
|
02 | Amy Vezza | Conflict Review State changed to Approved Request to Not Publish - announcement sent from Approved Request to Not Publish - announcement to be sent |
2017-08-07
|
02 | Benoît Claise | Conflict Review State changed to Approved Request to Not Publish - announcement to be sent from IESG Evaluation |
2017-08-07
|
02 | Benoît Claise | Benoit Claise took the Shepherding AD role, after Joel Jaeggli left the IESG. |
2017-03-26
|
02 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-03-26
|
02 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2017-03-25
|
02 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to Yes from Discuss |
2017-03-25
|
02 | Joel Jaeggli | New version available: conflict-review-irtf-nmrg-location-ipfix-02.txt |
2017-03-24
|
01 | Joel Jaeggli | New version available: conflict-review-irtf-nmrg-location-ipfix-01.txt |
2017-03-16
|
00 | Alvaro Retana | [Ballot comment] I agree with Alissa's point about BCP160. I agree with Stephen about the need for more review of this document. |
2017-03-16
|
00 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-03-16
|
00 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-03-16
|
00 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2017-03-16
|
00 | Benoît Claise | [Ballot comment] History information: My feedback on this draft has not changed (when it was draft-festor-ipfix-metering-process-location presented in IPFIX and draft-irtf-nmrg-location-ipfix in NMRG): authors, why … [Ballot comment] History information: My feedback on this draft has not changed (when it was draft-festor-ipfix-metering-process-location presented in IPFIX and draft-irtf-nmrg-location-ipfix in NMRG): authors, why don't you just request the IPFIX information elements from IANA? If they had gone the IANA route, they would have their IPFIX I.E.s by now. The authors have been pushing for years to publish their draft. They have requested feedback from IPFIX experts, but didn't go much information ... until lately with Paul Aitken (March 3rd," Review of draft-irtf-nmrg-location-ipfix-07.txt" on the IPFIX mailing list). btw, this is not a full review. However,, Paul Aitken, as the IANA expert, also provided feedback on the proposed IPFIX I.E.s part of draft-irtf-nmrg-location-ipfix-07 Cut and pasting Paul's latest information: Are you asking me to review draft-irtf-nmrg-location-ipfix before the telechat? Else, I would wait until there's a decision that it needs IETF review. Informally, all the technical content is reserved until the end. I've already reviewed section 6 and Appendix A for IANA under the IPFIX IE-doctors expert review process. Appendix B shows many incorrect IPFIX Templates which I've also already provided feedback for. I could review (rather than skim) the remainder of the draft in perhaps 1-2 hours. In short, this draft is a glorified IANA request. So if this document is published, it needs a version 8 based on the feedback provided and I needs 1-2 hours from Paul's time to make sure the entire document is fine from an IPFIX point of view. Now, back to the RFC5742 topic. 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 , but this relationship does not prevent publishing. 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. 4. The IESG has concluded that this document violates IETF procedures for 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. I would have chosen 6: document not necessary Now, assuming a version 8 with the Paul's first feedback and one more review (1-2 hours from Paul), the result is: 1. The IESG has concluded that there is no conflict between this document and IETF work. This document doesn't extend an IETF protocol (IPFIX) in a privacy-relevant manner, it just publishes some fields that contain some privacy-related information. That is the big distinction. From an OPS side, to configure the IPFIX metering process to monitor those new IPFIX information elements on a router, one needs to have the admin password. With this password, there are some many things that could be done in terms of privacy. So really, pretending that you will protect user privacy by not having this IPFIX I.E.s in IANA doesn't make sense to me. If the authors had requested those IPFIX I.E.s directly to IANA, nobody would have complained. Now, because it's a document, some wants "do not publish". I don't understand. Keep in mind that this is a "glorified IANA request". |
2017-03-16
|
00 | Benoît Claise | [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise |
2017-03-15
|
00 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from No Record |
2017-03-15
|
00 | Ben Campbell | [Ballot comment] I was going to enter a DISCUSS position about how the protections in BCP160 are inadequately conveyed by the language that it "MAY … [Ballot comment] I was going to enter a DISCUSS position about how the protections in BCP160 are inadequately conveyed by the language that it "MAY be applied..." But Alissa beat me to it. Otherwise, I agree with the rest of her comments, as well as Stephen's comments. |
2017-03-15
|
00 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2017-03-15
|
00 | Alissa Cooper | [Ballot discuss] I don't think this is the right conflict review response, for the two reasons below. I think one of the ones that requires … [Ballot discuss] I don't think this is the right conflict review response, for the two reasons below. I think one of the ones that requires IETF review and IESG approval might be, or DNP. First, this document makes recommendations inconsistent with BCP 160, which defines the location conveyance architecture that was standardized in the IETF in the GEOPRIV working group. The privacy properties of that architecture are not optional when attaching location to endpoints that identify targets, but this document says that their "usage MAY be applied to the IPFIX protocol when conveying location information." I consider that a conflict. Second, this document adds a column to an IANA registry that was defined in a standards-track RFC. Although the likelihood of interoperability problems as a result is small, I'm not sure this is really the right precedent to set. Should it really be the case that informational documents in the IRTF stream can change the structure of IANA registries defined in the standards track? |
2017-03-15
|
00 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2017-03-15
|
00 | Alia Atlas | [Ballot comment] I agree with Stephen's concerns. |
2017-03-15
|
00 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-03-15
|
00 | Stephen Farrell | [Ballot discuss] I believe this is the wrong response and that we should return a response to the effect that this draft is extending an … [Ballot discuss] I believe this is the wrong response and that we should return a response to the effect that this draft is extending an IETF protocol in a privacy sensitive manner and should therefore undergo an IETF LC. Or, I'd be fine with a DNP either. I raised this same point during IRSG review, yet there was no real discussion on that (that I saw) in the (is it?) six or so months since then. I do not think that clearing the decks for a new IRTF chair (as Lars has said he is doing by putting this up for conflict review) is a good enough reason to simply allow this pass. In fact, I think we ought be more willing to send a DNP or needs-IETF-LC response on that basis. The document itself clearly seems to envisage this location info being made available in a way that could directly track users. (" A typical example is a mobile device changing its location while exporting IP Flow records.") That the measurement ecosystem is not visible to users (and ought not be) is all the more reason to not want to have tracking added as a "feature" there - while ideas of "consent" on the Internet are badly broken, there seems to be basically no way in which a person could ever sensibly and knowledgeably agree to this kind of tracking. The security and privacy considerations are sadly lacking and would not IMO pass scrutiny in an IETF LC, (nor in the exam for my undergrad students;-), for example: "all Messages exchanged between Exporting and Collecting Processes SHOULD be signed and encrypted using Transport Layer Security (TLS) " ... is simply gibberish. TLS does not involve signing application data. That is yet another signal that this has not had and needs proper scrutiny. I note that the history here seems to be that this is an idea that garnered no traction in the IETF. We ought not allow this kind of workaround work for cases like that. And even moreso when (as in this case) the privacy issue was raised in IRSG review and no discussion whatsoever ensued. All in all: we should say no here. |
2017-03-15
|
00 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2017-03-15
|
00 | Joel Jaeggli | [Ballot comment] Work on ipfix was performed in the now concluded ipfix working group. Although this work was presented there, it was not adopted. The … [Ballot comment] Work on ipfix was performed in the now concluded ipfix working group. Although this work was presented there, it was not adopted. The ipfix information model is extensible, entities are registrable under the under the procedure of expert review. |
2017-03-15
|
00 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2017-03-15
|
00 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2017-03-15
|
00 | Joel Jaeggli | Created "Approve" ballot |
2017-03-15
|
00 | Joel Jaeggli | Conflict Review State changed to IESG Evaluation from AD Review |
2017-03-15
|
00 | Joel Jaeggli | New version available: conflict-review-irtf-nmrg-location-ipfix-00.txt |
2017-03-12
|
00 | Joel Jaeggli | Conflict Review State changed to AD Review from Needs Shepherd |
2017-03-02
|
00 | Joel Jaeggli | Telechat date has been changed to 2017-03-16 from 2017-03-02 |
2017-03-02
|
00 | Joel Jaeggli | Shepherding AD changed to Joel Jaeggli |
2017-02-28
|
00 | Cindy Morgan | Placed on agenda for telechat - 2017-03-02 |
2017-02-28
|
00 | Lars Eggert | IETF conflict review requested |