Subject: [IPFIX] Shepherd writeup for draft-ietf-ipfix-anon-04.txt

From: Nevil Brownlee <[email-masked]>
Date: Tue, 12 Oct 2010 14:33:45 +1300

Hi Dan:

Herewith the writeup for this IPFIX work item, please submit it
to IESG for review.

Thanks, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

Shepherd Document for draft-ietf-ipfix-anon-04.txt

   (1.a) Who is the Document Shepherd for this document? Has the
         Document Shepherd personally reviewed this version of the
         document and, in particular, does he or she believe this
         version is ready for forwarding to the IESG for publication?

   Nevil Brownlee.  I have reviewed this draft, I believe it's ready
     for publication.

   (1.b) Has the document had adequate review both from key WG members
         and from key non-WG members? Does the Document Shepherd have
         any concerns about the depth or breadth of the reviews that
         have been performed?

   Yes. It was developed over the last two years, and has had extensive
   discussion on the IPFIX list.  I have no concerns about its reviews.

   (1.c) Does the Document Shepherd have concerns that the document
         needs more review from a particular or broader perspective,
         e.g., security, operational complexity, someone familiar with
         AAA, internationalization or XML?

   No.  This is an Experimental draft; it simply explains
   the issues raised by the need to anonymise network trace data files,
   and sets out a method that can be used to describe how data carried
   via IPFIX was anonymised.

   (1.d) Does the Document Shepherd have any specific concerns or
         issues with this document that the Responsible Area Director
         and/or the IESG should be aware of? For example, perhaps he
         or she is uncomfortable with certain parts of the document, or
         has concerns whether there really is a need for it. In any
         event, if the WG has discussed those issues and has indicated
         that it still wishes to advance the document, detail those
         concerns here. Has an IPR disclosure related to this document
         been filed? If so, please include a reference to the
         disclosure and summarize the WG discussion and conclusion on
         this issue.

   Anonymising network data is a 'hot topic' just now within the Network
   Research community.  This draft summarises the IPFIX WG's views on
   anonymisation, and how flow data could be anonymised within IPFIX.
   No IPR disclosure has been made for this draft.

   (1.e) How solid is the WG consensus behind this document? Does it
         represent the strong concurrence of a few individuals, with
         others being silent, or does the WG as a whole understand and
         agree with it?

   The WG has reached full consensus on this draft.

   (1.f) Has anyone threatened an appeal or otherwise indicated extreme
         discontent? If so, please summarise the areas of conflict in
         separate email messages to the Responsible Area Director. (It
         should be in a separate email because this questionnaire is
         entered into the ID Tracker.)

   No.

   (1.g) Has the Document Shepherd personally verified that the
         document satisfies all ID nits? (See the Internet-Drafts Checklist
         and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
         not enough; this check needs to be thorough. Has the document
         met all formal review criteria it needs to, such as the MIB
         Doctor, media type and URI type reviews?

   Yes.  The checker complains about addresses that appear in examples
   not being 'documentation' addresses, but these are meant to be
   examples of anonymised addresses.

   (1.h) Has the document split its references into normative and
         informative? Are there normative references to documents that
         are not ready for advancement or are otherwise in an unclear
         state? If such normative references exist, what is the
         strategy for their completion? Are there normative references
         that are downward references, as described in [RFC3967]? If
         so, list these downward references to support the Area
         Director in the Last Call procedure for them [RFC3967].

   Yes.  All the normative references are to RFCs, there are no
   downward references.

   (1.i) Has the Document Shepherd verified that the document IANA
         consideration section exists and is consistent with the body
         of the document? If the document specifies protocol
         extensions, are reservations requested in appropriate IANA
         registries? Are the IANA registries clearly identified? If
         the document creates a new registry, does it define the
         proposed initial contents of the registry and an allocation
         procedure for future registrations? Does it suggest a
         reasonable name for the new registry? See [RFC5226]. If the
         document describes an Expert Review process has Shepherd
         conferred with the Responsible Area Director so that the IESG
         can appoint the needed Expert during the IESG Evaluation?

   Yes.  The IANA Considerations section asks for two new IPFIX
   Information Elements; they will simply need to be added to IANA's
   IPFIX IE Registry.

   (1.j) Has the Document Shepherd verified that sections of the
         document that are written in a formal language, such as XML
         code, BNF rules, MIB definitions, etc., validate correctly in
         an automated checker?

   There are no sections written in a formal language.

   (1.k) The IESG approval announcement includes a Document
         Announcement Write-Up. Please provide such a Document
         Announcement Write-Up? Recent examples can be found in the
         "Action" announcements for approved documents. The approval
         announcement contains the following sections:

      Technical Summary
   This document describes anonymisation techniques for IP flow data and
   the export of anonymised data using the IPFIX protocol.  It
   categorizes common anonymisation schemes and defines the parameters
   needed to describe them.  It provides guidelines for the
   implementation of anonymised data export and storage over IPFIX, and
   describes an information model and Options-based method for
   anonymisation metadata export within the IPFIX protocol or storage in
   IPFIX Files.

      Working Group Summary
   This draft has been worked on by WG members from ETH Zurich, and
   reviewed by other members, mostly European, who have similar research
   interests.  Although this seems a somewhat complicated way to transmit
   and store anonymised data, I believe it is a significant step towards
   a common (one day, Standard) way to carry metadata about how the
   anonymisation was done along with the data itself.  Although there was
   considerable discussion within the working group, consensus was
   reached without any problems.

      Document Quality
   This is an Experimental I-D, intended for the Network Research and
   Network Security communities.  It is submitted as an Experimental
   document; we do this as a way of encouraging multiple implementations,
   so as to gain experience with it.  When we have sufficient experience
   with this, we will bring it back to the Working Group to consider
   as a new Standards Track work item.

Nevil Brownlee
12 Oct 10

  - - - - - - - - - - -