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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Gen-art mailing list

Reply via email to