IETF conflict review for draft-irtf-nmrg-location-ipfix
conflict-review-irtf-nmrg-location-ipfix-02

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


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

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.