Re: Last Call: <draft-ietf-behave-ipfix-nat-logging-06.txt> (IPFIX Information Elements for logging NAT Events)

Paul Aitken <paitken@brocade.com> Mon, 07 March 2016 16:20 UTC

Return-Path: <paitken@Brocade.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9783F1B43AC; Mon, 7 Mar 2016 08:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1XbWU2tUfrb; Mon, 7 Mar 2016 08:20:55 -0800 (PST)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D441B43AB; Mon, 7 Mar 2016 08:20:54 -0800 (PST)
Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u27GGFTn013497; Mon, 7 Mar 2016 08:20:48 -0800
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 21fwy3dpb7-4 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 07 Mar 2016 08:20:48 -0800
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 09:20:28 -0700
Received: from [10.252.48.15] (10.252.48.15) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 17:20:24 +0100
Subject: Re: Last Call: <draft-ietf-behave-ipfix-nat-logging-06.txt> (IPFIX Information Elements for logging NAT Events)
To: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>, "draft-ietf-behave-ipfix-nat-logging@ietf.org" <draft-ietf-behave-ipfix-nat-logging@ietf.org>
References: <56BC9C63.3080404@brocade.com> <D2E3BF4A.168243%ssenthil@cisco.com> <56BF1786.5090607@brocade.com> <D2E764D8.168A91%ssenthil@cisco.com> <56D6F19D.6020102@brocade.com> <D30307FB.16B190%ssenthil@cisco.com>
From: Paul Aitken <paitken@brocade.com>
Message-ID: <56DDAA4A.80603@brocade.com>
Date: Mon, 7 Mar 2016 16:20:26 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0
MIME-Version: 1.0
In-Reply-To: <D30307FB.16B190%ssenthil@cisco.com>
Content-Type: multipart/alternative; boundary="------------080902080800070104010105"
X-Originating-IP: [10.252.48.15]
X-ClientProxiedBy: hq1wp-excas13.corp.brocade.com (10.70.36.103) To EMEAWP-EXMB11.corp.brocade.com (172.29.11.85)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-07_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603070292
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/rJbrYV6lGPEmzMBlOrtekxtlvME>
X-Mailman-Approved-At: Tue, 08 Mar 2016 08:59:12 -0800
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2016 16:20:57 -0000

Senthil, please see inline:

> Please see inline for [Senthil]
>
> From: Paul Aitken <paitken@brocade.com <mailto:paitken@brocade.com>>
> Date: Wednesday, March 2, 2016 at 8:58 AM
> To: Senthil Sivakumar <ssenthil@cisco.com 
> <mailto:ssenthil@cisco.com>>, 
> "draft-ietf-behave-ipfix-nat-logging@ietf.org 
> <mailto:draft-ietf-behave-ipfix-nat-logging@ietf.org>" 
> <draft-ietf-behave-ipfix-nat-logging@ietf.org 
> <mailto:draft-ietf-behave-ipfix-nat-logging@ietf.org>>
> Cc: "ietf@ietf.org <mailto:ietf@ietf.org>" <ietf@ietf.org 
> <mailto:ietf@ietf.org>>
> Subject: Re: Last Call: <draft-ietf-behave-ipfix-nat-logging-06.txt> 
> (IPFIX Information Elements for logging NAT Events)
>
> Senthil, I hadn't realised you'd published a new version of the draft. 
> Please CC me if/when you update it again.
>
> I've quickly reviewed the diffs between -06 and -07 :
>
>
> 1. Terminology
>
> " /Any non-IPFIX terminology used to convey NAT events are described 
> in //this section./"
>
> -> which section is "/this/" referring to? Since this paragraph seems 
> only to serve as an introduction to the third paragraph which only 
> contains a single exception, would it be better to remove these two 
> lines and go directly to the third paragraph? :
>     However, that causes
>     confusion in terminology used in NAT specific terms and IPFIX IEs.
>     Any non-IPFIX terminology used to convey NAT events are described in
>     this section.
> [Senthil]    How does this read?
>
>           The IPFIX Information Elements that are NAT specific are 
> created with
>
>         NAT terminology. In order to avoid creating duplicate IEs, IEs
>
>         are reused if they convey the same meaning.
>
>         This document uses the term timestamp for the Information 
> element which
>
>         defines the time when an event is logged, this is the same as 
> IPFIX
>
>         term observationTimeMilliseconds as described in [IPFIX-IANA]. 
> Since
>
>         observationTimeMilliseconds is not self explanatory for NAT 
> implementors,
>
>         this document uses the term timeStamp.
>
>

That's good.


> 2. Introduction
> "This document details the IPFIX Information Elements(IEs)"
> -> No need to repeat "(IEs)" since this was already explained in the 
> Terminology section.
>
> -> Remove the duplicated text:
>     The IPFIX Protocol [RFC7011] defines a generic push mechanism for
>     exporting information and events.  The IPFIX Information Model
>     [IPFIX-IANA] defines a set of standard IEs which can be carried by
>     the IPFIX protocol.This document details the IPFIX Information Elements(IEs) that MUST be 
> logged by a NAT device that supports NAT logging using IPFIX.   This document details the IPFIX Information
>     Elements(IEs) that MUST be logged by a NAT device that supports NAT
>     logging using IPFIX, and all the optional fields.  The fields
>     specified in this document are gleaned from [RFC4787] and [RFC5382].
>
> [Senthil] Done.
>
> 5.4. Quota exceeded Event types
>
> -> In the "/The events that can be reported are .../", I'd like to see 
> the text be identical to the items listed in table 3 to remove any 
> possible ambiguity.
>
> [Senthil] All of the events do match the table. The text is a little 
> more verbose and descriptive, so that the table doesn’t have to have 
> long text message.
> Let me know if the below is any better than before.
>
> The events that can be reported are the Maximum session
> entries limit reached, Maximum BIB entries limit reached, Maximum 
> (session/BIB) entries per user limit reached, Maximum active hosts limit
>      reached or maximum subscribers limit reached and
>      Maximum Fragments pending reassembly limit reached.
>              +---------------------------------------+--------+
>              |       Quota Exceeded Event Name       | Values |
>              +---------------------------------------+--------+
>              |        Maximum Session entries        |      1 |
>              |          Maximum BIB entries          |      2 |
>              |        Maximum entries per user       |      3 |
>              |  Maximum active hosts or subscribers  |      4 |
>              |  Maximum fragments pending reassembly |      5 |
>              +---------------------------------------+--------+

Good.


> 5.6.8.4.Global Address mapping high threshold reached
>
> -> Extra whitespace at the period: "paired address pooling behavior ."
>
> [Senthil] Done.
>
>
> 8.1. New Information Elements / natLimitEvent, natThresholdEvent,
>
> -> typo: " describer in Table below."
>
> -> you should remove the "Table 22" and "Table 23" descriptions under 
> those tables, because these won't make any sense when the text is 
> transcribed into IANA's registry. E
>
> [Senthil] I am not sure I understand why, because in section 8.1, for 
> natInstanceI, internalAddressRealm, externalAddressRealm we have this 
> format of name/description/data type and references.
> Why is natLimitEvent and natThresholdEvent different just because they 
> have their values defined?

You misunderstand: I mean the description text immediately underneath 
the tables, specifically the text which says: "/Table 22: Quota Exceeded 
event table/", "/Table 23: Threshold event table/", and "/Table 24: NAT 
Event ID table/". I'm not talking about the table contents.

IANA will take the relevant sections from your draft into their IPFIX 
registry. While "Table NN: whatever" makes perfect sense in the draft, 
it makes no sense in IANA's IPFIX registry - so IANA would have to 
selectively edit the definition you're providing. While I'm sure they're 
capable of doing that, the issue would be avoided if those tables didn't 
have descriptions.


> 8.2. Modified Information Elements / natEvent
>
> -> Again, you can't modify the definitions of the existing values.
>
> [Senthil] Is there a process on how to modify/deprecate the previously 
> defined values and replace it with new ones?

You can't modify the existing values, because there could be an unknown 
number of existing devices already using those values. I hope that IANA 
has already sent you feedback from the IPFIX expert reviewers indicating 
the best way forward.

P.