[Gen-art] Gen-ART Telechat review of draft-ietf-behave-ipfix-nat-logging-11

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 28 November 2016 17:06 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4FE54129538 for <gen-art@ietfa.amsl.com>; Mon, 28 Nov 2016 09:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kaAJp5Y2h5ap for <gen-art@ietfa.amsl.com>; Mon, 28 Nov 2016 09:06:29 -0800 (PST)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4051294A3 for <gen-art@ietf.org>; Mon, 28 Nov 2016 09:06:29 -0800 (PST)
Received: from resomta-ch2-13v.sys.comcast.net ([]) by resqmta-ch2-10v.sys.comcast.net with SMTP id BPNHcCNVzRingBPNsciodd; Mon, 28 Nov 2016 17:06:28 +0000
Received: from [] ([]) by resomta-ch2-13v.sys.comcast.net with SMTP id BPNscNqdUnC65BPNsc9xzV; Mon, 28 Nov 2016 17:06:28 +0000
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: "draft-ietf-behave-ipfix-nat-logging.all@ietf.org" <draft-ietf-isis-prefix-attributes.all@ietf.org>
References: <56818AED.8090909@alum.mit.edu>
Message-ID: <bda7fe94-8adc-3117-c329-c8b266ce0059@alum.mit.edu>
Date: Mon, 28 Nov 2016 12:06:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <56818AED.8090909@alum.mit.edu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfISZ6PoqGjSRIZO5lvhQJIuofMlE44JkCqvYCJ0JpN11mLku4Es+dKFnndeV+DxiatfXqo1RNIcL0hLpk75z+O9xFVJ4bQe5+lYSY913Nbv1FwvSjkw7 tEsQcK8+HCDkWVdM6wRGebKVaPnXJFwabv0Q2smvseMpRJ6hOxfN3eYu5YWi9W+sMhAQjRBRB+AT3Q38WcI+pLsr1KBXXTbx2O8MzHMHcU/pkl5+xu6spz8s XEQUq4uiqYOZj/D79Sdlgg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/S7KvKGGpHqOIyqG-_0ZFZyM2jK8>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-behave-ipfix-nat-logging-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2016 17:06:30 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 

Document: draft-ietf-behave-ipfix-nat-logging-11
Reviewer: Paul Kyzivat
Review Date:
IETF LC End Date: 2016-02-12
IESG Telechat date: 2016-12-01


This draft is on the right track but has open issues, described in the 

Major: 0
Minor: 5
Nits:  1

(1) Minor:

A sentence in Section 3 says: "This document focuses exclusively on the 
specification of IPFIX IEs." But this statement appears to be false. A 
large part of the document (Section 5.6) specifies Templates. It appears 
to be an important aspect of the document that goes beyond specifying 
just IEs. So the statement should be expanded.

(2) Minor:

Section 5.2 starts with "The templates could contain a subset of the 
Information Elements(IEs) shown in Table 1 depending upon the event 
being logged."

This is not a normative statement. It isn't clear what is normative 
regarding the use and content of templates. If I understand RFC7011, a 
NAT device can use any number of templates, and those templates can 
reference any defined IE. Is *this* document intended to *restrict* the 
form and number of templates used for logging NAT devices? Or is it 
simply suggesting some templates that may be modified as desired to fit 
the needs of a particular NAT device device?

These templates do not have any Information Element that uniquely 
identifies to the IPFIX collector that this template is being used. So 
how does the collector know that the particular event is intended to 
follow the definitions in this draft, rather than simply some 
proprietary template? Absent that, how do normative statements of what 
must be in the template mean anything?

(3) Minor:

Section 5.6 says: "Depending on the implementation and configuration 
various IEs specified can be included or ignored."

What is the normative intent of this statement? Is it defining what is 
meant by the "Mandatory" field in the tables? (I.e., that in the 
templates it sends the NAT device MUST include fields with Mandatory=Yes 
but MAY omit fields with Mandatory=No.) This should be revised to make 
the normative behavior clearer.

(4) Minor:

Within the IANA Considerations, section 8.1 deals with Information 
Elements, with one subsection for each new IE being defined. Some of 
these (8.1.4 natQuotaExceededEvent, 8.1.5 netThresholdEvent, 8.1.6 
netEvent) each require a new IANA subregistry to be defined. They do 
this rather informally within the body of the corresponding subsection. 
Perhaps IANA will figure this out, but there is opportunity for 
misunderstanding. It would be better if there were separate subsection 
of section 8 for each of these registry creation actions. E.g. 8.2 NAT 
Quota Exceeded Event Type, 8.3 NAT Threshhold Event Type, 8.4 NAT Event 

(5) Minor:

Section 9 appears to be normative, since it uses 2119 language. But it 
appears at a position in the document (after Acknowledgements and IANA 
Considerations, before Security Considerations), where I would normally 
not expect to find normative language.

Perhaps this is intended to be more of an appendix. If so, then the 
normative language should be removed, and it ought to be formatted as an 

If it is intended to be normative, then I suggest that it be moved ahead 
of the Acknowledgements.

(6) Nit:

Running IDNits returns a number of issues, mostly regarding references.