Skip to main content

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