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.
Jari On 28 Nov 2016, at 19:06, Paul Kyzivat <pkyzi...@alum.mit.edu> 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > 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 > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
