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

Jari Arkko <> Thu, 01 December 2016 09:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8A071295CD; Thu, 1 Dec 2016 01:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ySgP3nndd9MP; Thu, 1 Dec 2016 01:38:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 780D7129C87; Thu, 1 Dec 2016 01:35:51 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD4D82CCAE; Thu, 1 Dec 2016 11:35:50 +0200 (EET) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XTYyV81jKkz5; Thu, 1 Dec 2016 11:35:50 +0200 (EET)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id E9A332CC95; Thu, 1 Dec 2016 11:35:49 +0200 (EET) (envelope-from
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_7A73E04E-000C-425D-B882-442FB19EC39B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Jari Arkko <>
In-Reply-To: <>
Date: Thu, 01 Dec 2016 11:35:49 +0200
Message-Id: <>
References: <> <>
To: Paul Kyzivat <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: "" <>, General Area Review Team <>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-behave-ipfix-nat-logging-11
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Dec 2016 09:38:22 -0000

Thanks much for your review, Paul!

Do the authors have any comments? Paul’s review comments should be addressed. I think that at least the Section 5.6 question is something that you must address.


On 28 Nov 2016, at 19:06, Paul Kyzivat <> wrote:

> 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
> Summary:
> This draft is on the right track but has open issues, described in the review.
> 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 Type.
> (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 appendix.
> 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.
> _______________________________________________
> Gen-art mailing list