Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA5412D881 for ; Mon, 15 Jan 2018 14:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 rUty1FbJJYyn for ; Mon, 15 Jan 2018 14:35:20 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 0E0FE124BAC for ; Mon, 15 Jan 2018 14:35:20 -0800 (PST) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0FMXnPv138271 for ; Mon, 15 Jan 2018 17:35:16 -0500 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.73]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fh0a5v8nm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 15 Jan 2018 17:35:16 -0500 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Mon, 15 Jan 2018 22:35:15 -0000 Received: from us1a3-smtp03.a3.dal06.isc4sb.com (10.106.154.98) by smtp.notes.na.collabserv.com (10.106.227.90) with smtp.notes.na.collabserv.com ESMTP; Mon, 15 Jan 2018 22:35:12 -0000 Received: from us1a3-mail64.a3.dal09.isc4sb.com ([10.142.3.135]) by us1a3-smtp03.a3.dal06.isc4sb.com with ESMTP id 2018011522351202-1138781 ; Mon, 15 Jan 2018 22:35:12 +0000 In-Reply-To: From: "Wayne Tackabury" To: ipfix@ietf.org Date: Mon, 15 Jan 2018 22:35:12 +0000 Sensitivity: References: MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) X-Mailer: IBM Verse Build 15909-1273 | IBM Domino Build SCN1734600_20171212T0033_FP3 January 05, 2018 at 15:38 X-LLNOutbound: False X-Disclaimed: 42615 X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 x-cbid: 18011522-3107-0000-0000-0000049D4CCE X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.423878; ST=0; TS=0; UL=0; ISC=; MB=0.118706 X-IBM-SpamModules-Versions: BY=3.00008385; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000245; SDB=6.00975557; UDB=6.00494457; IPR=6.00755484; BA=6.00005778; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019056; XFM=3.00000015; UTC=2018-01-15 22:35:13 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2018-01-15 19:58:38 - 6.00007912 x-cbparentid: 18011522-3108-0000-0000-00007DD653F2 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-15_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [IPFIX] RFC 8158 applicability and breadth X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 22:35:21 -0000
Hi all:
 
I have two questions, and will separate them since they'r= e distinct, IPFIX-wise.
 
I'm noting the presence of RFC 8158, have briefly gone ov= er it.  It addresses IEs for "logging NAT events".
 
My question is this: in the formulation of these entities= , was the intent to have this be strictly the reporting domain for "classic= " NAT implementations, with configured pools and ports and static vs. dynam= ic mappings and all of that? 
 
Or, was there a considered "mission creep" :) to allow th= ese to be used for reporting on things like load balancers, firewall domain= address mapping, and the like, to report what their "pre-translated" addre= ss is on the source of a flow?  Keep in mind, the mapping for such a t= hing has nothing to do with the exporter itself (the exporter may just be d= etecting this from network traffic), so it would be quite wrong to use a so= urce vs. exporter address.
 
If using the RFC 8158 fields for this just seems....wrong= (I mean, it is translation....of an address), is there another (probably s= impler) set of fields for this that come to mind?  To be perfectly tra= nsparent here, if this was to be used for supporting the semantics of the "= Forwarded: " HTTP header as in RFC 7239, this would in fact have to be a li= st of addresses, but I'm just wondering if there was an IPFIX reporting pra= ctice for this using IANA elements even if the forwarded source was a scala= r address.
 
Thanks!
Wayne