From nobody Thu Oct 2 18:17:22 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFEB1ACFBE for ; Thu, 2 Oct 2014 18:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.987 X-Spam-Level: X-Spam-Status: No, score=-14.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 c-1wvXpr3yZA for ; Thu, 2 Oct 2014 18:17:14 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA6D1ACFBA for ; Thu, 2 Oct 2014 18:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1718; q=dns/txt; s=iport; t=1412299034; x=1413508634; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=4zbVR2eV0SQTEtIZvarV++BNS4AEASdgtxtbgqlQcts=; b=NK5jU9IKtfnZ2FzrTBHR4GE7eQR4oG53RlDRftEfWxqNua1wUvM1KD/w G5s2MOsGIl0CSJMdVRSR6x/fHxH6oOf0SYvp1lyvB61Cr6BeDU18gUe5C E3o0/HBoTy3es5NQnkbYmqa4JJxYKKdVZyvG6Uq9gpkbnCSb+CzJ/Peok U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOv3LVStJA2G/2dsb2JhbABfgw5Ty06IVhYBe4REik4NmHqlLhMEkEODF4EeBYtailSHDZV7hAMdgnkBAQE X-IronPort-AV: E=Sophos;i="5.04,642,1406592000"; d="scan'208";a="360287779" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 03 Oct 2014 01:17:13 +0000 Received: from sjc-vpn7-501.cisco.com (sjc-vpn7-501.cisco.com [10.21.145.245]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s931HBjC015388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 3 Oct 2014 01:17:13 GMT From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 2 Oct 2014 18:16:33 -0700 To: behave@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/behave/JJd3skLFTGAj0HnJt0Z3-5DVvlU Subject: [BEHAVE] draft-donley-behave-deterministic-cgn-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:17:16 -0000 I see draft-donley-behave-deterministic-cgn was updated to -08. = Unchanged from -07 is this statement in its Security Considerations: Note that with the possible exception of cryptographically-based port allocations, attackers could reverse-engineer algorithmically-derived port allocations to either target a specific subscriber or to spoof traffic to make it appear to have been generated by a specific subscriber. However, this is **exactly** the same level of security = that the subscriber would experience in the absence of CGN. Emphasis on "exactly" is mine. I am puzzled by this still being = "exactly" when the draft itself cites RFC6056,=20 There are trade-offs to be made between the sizes of these port groups, the ratio of public addresses to subscribers, whether or not these groups timeout, and the impact on logging requirements and port randomization security (RFC6056) = [RFC6056]." A 4000-port range (as used in the example) with overflow is not exactly = the same security exposure as 65355 ports -- and RFC6056 says so, = https://tools.ietf.org/html/rfc6056#page-9: It is also worth noting that, provided adequate algorithms are in use, the larger the range from which ephemeral ports are selected, the smaller the chances of an attacker are to guess the selected port number. draft-donley-behave-deterministic-cgn would be improved by making it = clear, in its security considerations, that the reduced port range is a = harm to end host security. I suggest: By reducing the ephemeral port numbers available to hosts behind a = CGN, those hosts are subject to an increased attack surface [RFC6056]. -d From nobody Fri Oct 3 18:28:32 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2E01A89FE for ; Fri, 3 Oct 2014 18:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 Ybv0O-RLlGoE for ; Fri, 3 Oct 2014 18:28:29 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7EC1A89FC for ; Fri, 3 Oct 2014 18:28:29 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so213399igb.8 for ; Fri, 03 Oct 2014 18:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=db517+Z4ZfI24s3vPS4DUokPVyUX8NzaK7iK8PCbt7Q=; b=zoxuVSJOJbEkdAvVJkmtmXhNWFb7m7k4OzZwnZBCU62OExL/vdU3+Gs8F2Z/apWZFS VWY1QZXoqI79LvxxuwnmeqUKpckUwO5LQ4dnIYobPTge+2k1Ae6tN9sPQnS+CqFGjSA7 WdRPDn5ikvGsIlDRHcLEH2oXDrOYtdDV0grwKJwMAS5E7z4WPGQt4Fs9oQtXsvSBpcFX TiXapxxbEn34Du6Bi6ScFE4XHCO0JbtuRI9q4B3f8pc098aRQAXHPmwDoqS0fieQajOz +DFX88O/9NwK0kOu3Qf7RrJaLk1JoyPvl7TW+TsgkixubVOn4Lm72bs6VkRUCFxeHbPF 8hUw== X-Received: by 10.50.80.116 with SMTP id q20mr2820513igx.22.1412386108015; Fri, 03 Oct 2014 18:28:28 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-27-2.tor.primus.ca. [173.206.27.2]) by mx.google.com with ESMTPSA id z5sm3237294igl.21.2014.10.03.18.28.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Oct 2014 18:28:27 -0700 (PDT) Message-ID: <542F4D34.9090400@gmail.com> Date: Fri, 03 Oct 2014 21:28:20 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , draft-ietf-behave-nat-mib.authors@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/lT8qayC-WEKrwrchulRtwJKYPN4 Subject: [BEHAVE] NAT MIB: Missing link between natPoolEntry and natPoolRangeTable X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 01:28:30 -0000 I'm doing the NAT MIB issue tracker at last, after getting a bunch of other stuff out of the way. I noticed that there is no current link between natPoolEntry and natPoolRangeTable. I assume there should be. I've classed this as a minor issue, resolvable by the design team with report back to the list. Tom Taylor From nobody Mon Oct 6 08:06:36 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7F41A0310 for ; Mon, 6 Oct 2014 08:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 fOkrGjmstoNX for ; Mon, 6 Oct 2014 08:06:33 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191091A0194 for ; Mon, 6 Oct 2014 08:06:32 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so4494418lbi.9 for ; Mon, 06 Oct 2014 08:06:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=42qCUyphVGNB+gGQIdUNsqJQORkBf5e8mWRNFhaBpxA=; b=NLvldLbng3/b02HNGC/OVvAGJTzMWQv6Mt8vBIYTAqrEChtOVEGJvT6FUX7D4oEFEJ FsmoKG7mgFeUUx4RdrPWxj0gij+skzKyoBlQqxZFemZMwHEbO1MKc+LpiK1Uwx1/Tt+3 xQrrgYKe9ovOq6NUmJV4V+84tFij0JU96iPrGB8msewk4d+zfF+KlA6qF1NUUkubmcJe uHv3PjQEHs4ByR1jlyAr9Nu5VoqqtC7fcMxbLJKBerZKDSMWqKfAwuHs+eTVjR9TtXyw bE6Y8sbNyKOUxg8G1gLZ49l+WtYPqIMer4P2ao0YVqyGrOuaUpP7d8ExZaAd7FMnKEq5 Ae9Q== X-Gm-Message-State: ALoCoQmlAkphZPbPglfVg+r/Xd2csirMBgq3kV6c9T1hTzunpyRipwUi5+RknD5Gc9QfjPjlkavC MIME-Version: 1.0 X-Received: by 10.112.130.41 with SMTP id ob9mr24230858lbb.12.1412607991392; Mon, 06 Oct 2014 08:06:31 -0700 (PDT) Received: by 10.25.137.213 with HTTP; Mon, 6 Oct 2014 08:06:31 -0700 (PDT) In-Reply-To: <542F4D34.9090400@gmail.com> References: <542F4D34.9090400@gmail.com> Date: Mon, 6 Oct 2014 17:06:31 +0200 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=047d7b342ba688c3860504c26d50 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/N74RkhStg1SQU0epIcZFZotOKFI Cc: "behave@ietf.org" , draft-ietf-behave-nat-mib.authors@tools.ietf.org Subject: Re: [BEHAVE] NAT MIB: Missing link between natPoolEntry and natPoolRangeTable X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:06:34 -0000 --047d7b342ba688c3860504c26d50 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 4, 2014 at 3:28 AM, Tom Taylor wrote: > I noticed that there is no current link between natPoolEntry and > natPoolRangeTable. Is this not what you're looking for? natPoolRangePoolIndex OBJECT-TYPE SYNTAX NatPoolId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of the address pool to which this address range belongs. See natPoolIndex." ::= { natPoolRangeEntry 1 } Simon --047d7b342ba688c3860504c26d50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sat, Oct 4, 2014 at 3:28 AM, Tom Taylor <tom.taylor.stds@gmail.= com> wrote:
I noticed that there is no cu= rrent link between natPoolEntry and natPoolRangeTable.

Is this not what you're looking for?= 

   natPoolRangePoolIndex OBJECT-TYPE
       SYNTAX NatPoolId
       MAX-ACCESS not-accessible
       STATUS current
       DESCRIPTION
           "Index of the address pool to which this address range
            belongs.  See natPoolIndex."
       ::=3D { natPoolRangeEntry 1 }

Simon
--047d7b342ba688c3860504c26d50-- From nobody Mon Oct 6 12:41:43 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5D41A1B7F for ; Mon, 6 Oct 2014 12:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 NCJ-EGIb804o for ; Mon, 6 Oct 2014 12:41:40 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83DD1A1B67 for ; Mon, 6 Oct 2014 12:41:40 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so4037401iec.29 for ; Mon, 06 Oct 2014 12:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iXQlsF6rpUE5zNKkvNQwSSch7Fg/dWGhQmnWZ3JFhwI=; b=ktP85vSo2l8LBpW+bUzyYWfJJocX8ZJD69GOiJoF45vC5lZW3ADiblJOt0SeIOJ2Ts e09zvdsKW/y18z24YuMyxZmW+r9+Q/lyGe8d3i53hHZ1k16glIdWoTD0GJQ+YVJftv9+ IdS4DbYKck9GhUfO39Pyn026MLV00YWv+x/hfUBmuEgUIqE2wQoblsR8MXs0+ueHza6u TF+0fjMUgNm7eZhdqV9GzNW5JE5UPQZmTZLM2EiknOXOQVkMtz9v6V+kOz4Dxu++hOCd CQMZmGYkBb9TatWiS0Bin62/SnMsnZWWDtBgx+DpexsFPQcI+Bim1c1PgWodKIoFb3Im s8Cg== X-Received: by 10.42.101.199 with SMTP id f7mr15178522ico.4.1412624500187; Mon, 06 Oct 2014 12:41:40 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-14-157.tor.primus.ca. [173.206.14.157]) by mx.google.com with ESMTPSA id j2sm10303562igm.21.2014.10.06.12.41.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 12:41:39 -0700 (PDT) Message-ID: <5432F06E.7060301@gmail.com> Date: Mon, 06 Oct 2014 15:41:34 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <542F4D34.9090400@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/xB49wkBPQ96fP6OBT819dBzgqjc Cc: "behave@ietf.org" , draft-ietf-behave-nat-mib.authors@tools.ietf.org Subject: Re: [BEHAVE] NAT MIB: Missing link between natPoolEntry and natPoolRangeTable X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 19:41:42 -0000 I expected it in the opposite direction. What I really have in mind is David Harrington's comment in Behave Tracker #17: "I'm not convinced you need the extra hierarchy of natCounters and natLimits and natPoolObjects, but I can live with it." I've listed natCounters and natPoolObjects as minor issues for us to resolve. The basic question in this case is whether simply to fold the range entries into natPoolObjects. Tom On 06/10/2014 11:06 AM, Simon Perreault wrote: > On Sat, Oct 4, 2014 at 3:28 AM, Tom Taylor > wrote: > >> I noticed that there is no current link between natPoolEntry and >> natPoolRangeTable. > > > Is this not what you're looking for? > > natPoolRangePoolIndex OBJECT-TYPE > SYNTAX NatPoolId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Index of the address pool to which this address range > belongs. See natPoolIndex." > ::= { natPoolRangeEntry 1 } > > > Simon > From nobody Mon Oct 6 12:54:15 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5C71A88C5 for ; Mon, 6 Oct 2014 12:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NUhj6gXb1D0E for ; Mon, 6 Oct 2014 12:54:08 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542931A87EE for ; Mon, 6 Oct 2014 12:54:08 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z11so4770183lbi.41 for ; Mon, 06 Oct 2014 12:54:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qZmcRFQMjWk/4dWHwS7GZVvJv9ZKBX9Lp+q1uljQHOI=; b=l0Bar1ta/5XX6UJwfuw1Ij4Z60VEoZir8LQ0LGi00fJLwERWg1BbZrtg05BuFtNcbB fb5Q8qMqYWw7/X+ZEyxxOUxD6pm+qgB0NjAoT15fvvCXsTpvOnppkO8FyWZpYhEZ/YT4 h/J0O3KKTQ9e6700TRkrLoERimj23JPGVC2lMMZWj2VgtEylAdDj2d2yv9/1Eb+NVrM+ RrAKEMDjF69gLyE8SLacYciSpir5JmCVNMNaPW9HOwXVYss/5jBiFBZLztvP7S3VN4yU 6KEZnF98YFIfyIhlqBuRn2gXP59SZUNFGmYOxbUdLdJSS+lteH5vuXhxmC4NYZCiU+12 5Iew== X-Gm-Message-State: ALoCoQl7IOQt28ITa7L1lfhbTFSsQTmWnosyEyj1GpE82OOMBfBYaaxqlaRP4u/lN0E361qf/zoG MIME-Version: 1.0 X-Received: by 10.112.125.131 with SMTP id mq3mr23355629lbb.20.1412625246498; Mon, 06 Oct 2014 12:54:06 -0700 (PDT) Received: by 10.25.137.213 with HTTP; Mon, 6 Oct 2014 12:54:06 -0700 (PDT) In-Reply-To: <5432F06E.7060301@gmail.com> References: <542F4D34.9090400@gmail.com> <5432F06E.7060301@gmail.com> Date: Mon, 6 Oct 2014 21:54:06 +0200 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=089e011777c904c97d0504c672a6 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/8qJ_KWzNXdRrKCg3hWZXbH3Gjzo Cc: "behave@ietf.org" , draft-ietf-behave-nat-mib.authors@tools.ietf.org Subject: Re: [BEHAVE] NAT MIB: Missing link between natPoolEntry and natPoolRangeTable X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 19:54:11 -0000 --089e011777c904c97d0504c672a6 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 6, 2014 at 9:41 PM, Tom Taylor wrote: > I expected it in the opposite direction. I don't see how that would be possible. A pool can have multiple ranges, but a range always belongs to a single pool... > What I really have in mind is David Harrington's comment in Behave Tracker > #17: > > "I'm not convinced you need the extra hierarchy of natCounters and > natLimits and natPoolObjects, but I can live with it." > Yeah, we don't strictly "need" it. The basic question in this case is whether simply to fold the range entries > into natPoolObjects. The range entries table is already part of natPoolObjects: natPoolRangeTable OBJECT-TYPE SYNTAX SEQUENCE OF NatPoolRangeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains address ranges used by pool entries." ::= { natPoolObjects 2 } Simon On 06/10/2014 11:06 AM, Simon Perreault wrote: > >> On Sat, Oct 4, 2014 at 3:28 AM, Tom Taylor >> wrote: >> >> I noticed that there is no current link between natPoolEntry and >>> natPoolRangeTable. >>> >> >> >> Is this not what you're looking for? >> >> natPoolRangePoolIndex OBJECT-TYPE >> SYNTAX NatPoolId >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "Index of the address pool to which this address range >> belongs. See natPoolIndex." >> ::= { natPoolRangeEntry 1 } >> >> >> Simon >> >> --089e011777c904c97d0504c672a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 6, 2014 at 9:41 PM, Tom Taylor <tom.taylor.stds@gmail.com<= /a>> wrote:
I expected it in the opposite dir= ection.

I don't see how that would be p= ossible. A pool can have multiple ranges, but a range always belongs to a s= ingle pool...
=C2=A0
What I really have in= mind is David Harrington's comment in Behave Tracker #17:

"I'm not convinced you need the extra hierarchy of natCounters and= natLimits and natPoolObjects, but I can live with it."

Yeah, we don't strictly "need" it.

The basic question in this case is whether= simply to fold the range entries into natPoolObjects.
The range entries table is already part of natPoolObjects:

   natPoolRangeTable OBJECT-TYPE
       SYNTAX SEQUENCE OF NatPoolRangeEntry
       MAX-ACCESS not-accessible
       STATUS current
       DESCRIPTION
           "This table contains address ranges used by pool entries.&q=
uot;
       ::=3D { natPoolObjects 2 }
=C2=A0

--089e011777c904c97d0504c672a6-- From nobody Wed Oct 15 18:21:05 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE631ACEB7 for ; Wed, 15 Oct 2014 18:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 tGyCQhXGCuEZ for ; Wed, 15 Oct 2014 18:21:02 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F5E1ACEB5 for ; Wed, 15 Oct 2014 18:21:02 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id ar1so2478259iec.38 for ; Wed, 15 Oct 2014 18:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=4QPOrzbGhk48IKmDgqOKyREUHQyDqDUTnaJskFWWgYA=; b=nAirKTqqgB+I4SN5IbKHB0m+3mVMVNmUnYa4KFKsx5CvPTbDGueHKKMAolumR4K/S2 Cm1XHMsYefvG31kSsEMtJQ3fm8QEhH4tYX01rDGwavqiZLHmhuxiXw9GEZ+R35E+NsQU 3TzF+z5lLNiZ1WbeKowqsXpVIq5Gc2Wn7LKVZ7apfOOFrjC9MPbysMet9p/esEMEHKLQ ZnWZtznqaiO5x0v/b/CXyt2xMrs6fsCYZ9Wpfkh0QGxAnHCjf5+sv+SGt/k7iAJCk8Lk 7Bpn90Lo9Cq9MYAnYwtwS1tL953tSxayWmTTlMPYLPYwCPGsu7C1SWnTm4RKoogiPAZI 1ItQ== X-Received: by 10.107.32.1 with SMTP id g1mr13956907iog.13.1413422461433; Wed, 15 Oct 2014 18:21:01 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-79-65.tor.primus.ca. [173.206.79.65]) by mx.google.com with ESMTPSA id k127sm291513ioe.24.2014.10.15.18.21.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 18:21:01 -0700 (PDT) Message-ID: <543F1D7A.8070506@gmail.com> Date: Wed, 15 Oct 2014 21:20:58 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , draft-ietf-behave-nat-mib.authors@tools.ietf.org, Spencer Dawkins , David Harrington Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/vuRSPyP8ErMhT08MNLocppOTmjg Subject: [BEHAVE] Issue tracker for NAT MIB document (draft-ietf-behave-nat-mib) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 01:21:03 -0000 Having cleared a number of other matters away, I finally got to work on the issue tracker for the NAT MIB document. I'm about half-way through entering the details for the individual issues. The entry point into the tracker is http://trac.tools.ietf.org/wg/behave/trac/wiki/PostIssueTracker The only live project link on that page for the moment is "NAT MIB v2". Clicking on that link takes you to the Issue Index page for this project. As you will see, this page records 39 issues to which we may add more in further discussions. All of the issues identified by Tracker Tickets #15 to #19 have been captured as individual items, along with the issues identified by David Harrington's review. Getting from the Issue Index page to the details of a specific issue is explained on that page. I've only done Issues 1-17 as of this moment, but it shouldn't take long to do the rest. As explained on the Project page, major issues are those that change MIB content or affect operations, and are resolved through list discussion. Minor issues are resolved by the design team, with results reported to the Behave list. Feel free to comment on how I have classified the issues. At the moment I've identified 8 major issues and 24 minor ones still open. I will be initiating discussion of the major issues in separate E-mails. Tom Taylor From nobody Sat Oct 18 12:36:09 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2BA1A01E5; Sat, 18 Oct 2014 12:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 J3dC54NoU2Ku; Sat, 18 Oct 2014 12:36:05 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7079D1A01A8; Sat, 18 Oct 2014 12:36:05 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id tr6so2624463ieb.33 for ; Sat, 18 Oct 2014 12:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=YU6wMnfJAx2c1322uCzgqlI2ZAtoe/5qIMYGEzg/x+I=; b=FPr+340QOW5IONvQGoCpZjlSUWq1GRxYVLJhHdqvRI1xTlDYIBEYR7TzCTOhVjhJNx 4hbtDW7CJb3vICtIzzfgK7X+X+gCBtN6Rf3GH5oe4l5BQT+sX48UZ2i+x4hD/lGOWzli ocYujiRJ0OPV1Kwpvj7PZPE4TYbzJaXFw3kVKh3GNw+ETwBv1Bz+SlbiGqJG4XtyugD4 fZf0vlua9ffgvPGcJvznTybYeZveGQT1hg8xwu8SLBeUsiPh1g9eolRhLCDEehVJgcOA H1DTg1ocuSC4xb3ENbUJ6QSXOO2uTOuxt2R1R9HAMx/AAANV1OlUHhl7X5ndCF0eQLzF qAyw== X-Received: by 10.43.153.131 with SMTP id la3mr17267979icc.38.1413660964852; Sat, 18 Oct 2014 12:36:04 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-91-240.tor.primus.ca. [173.206.91.240]) by mx.google.com with ESMTPSA id gb12sm1541736igd.0.2014.10.18.12.36.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Oct 2014 12:36:04 -0700 (PDT) Message-ID: <5442C124.8070904@gmail.com> Date: Sat, 18 Oct 2014 15:36:04 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: draft-ietf-behave-mib.authors@tools.ietf.org, "opsawg@ietf.org" , "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/YmcVs61dyPP_y61VSwc8w_auIkA Cc: Spencer Dawkins Subject: [BEHAVE] Splitting of draft-ietf-behave-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 19:36:07 -0000 draft-ietf-behave-mib (http://tools.ietf.org/html/draft-ietf-behave-nat-mib) has been undergoing AD-sponsored process. I have completed setting up an issue tracker based on the issues raised in the Behave Trac tickets #16-19 and the 45 comments generated by David Harrington in his detailed review. The entry point to that issuee tracker is at http://trac.tools.ietf.org/wg/behave/trac/wiki/PostIssueTracker One of the issues was procedural. The current draft deprecates all of the objects in the original NAT MIB module (RFC 4008) and then goes on to define new objects using the same MIB module name. There seems to be agreement that instead, there will be one I-D for the deprecation of NAT-MIB and a second I-D to define NAT-MIB-V2. RFC 4008 will be declared Historic. Do I have the procedure right, and are there any other comments? Tom Taylor From nobody Sun Oct 19 17:29:12 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B481A1A63; Sun, 19 Oct 2014 17:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 4n1hH4gncYyS; Sun, 19 Oct 2014 17:29:03 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCEB1A1A5D; Sun, 19 Oct 2014 17:29:03 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id hn15so5545570igb.5 for ; Sun, 19 Oct 2014 17:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yKUU1d/E/55hZJy7yrLBogxYZaUkrI1OdOf0keh2cxI=; b=JQ5hEGd5C/DtkauIXrEQYOsyZRypfn0hdwiMI5HPHUbVAOIyw6P3mcKHLoERvvDDOb Z3UDRewuu8mSC3GfBOju4jYbQvsUL9TrQL+THPrAMm1Yqjd3lTx2i3HuAyuGu0K7l1et 1r3pqk6nHXxnc+Wo4Tz94FuxndAfxvJzvsHggqSCMuJDCjtAtJ9jdLSLA3Hc/rTeJGij 8h/0wmUe4oTtKvksuIj4cc3b+2yVQHGIK8H85og8IMH310/i5JXkve/1su4z6Iyn4hzd LZ7iN2a0QKBb25/xZH34Fpi4F0X/Yf4oJBnkJaiIldlVXbk7q20eX9igvFw3jTclEqKr 8rzQ== X-Received: by 10.42.250.17 with SMTP id mm17mr23282112icb.18.1413764942612; Sun, 19 Oct 2014 17:29:02 -0700 (PDT) Received: from [192.168.0.102] ([64.56.228.254]) by mx.google.com with ESMTPSA id n84sm3844735ioe.19.2014.10.19.17.29.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Oct 2014 17:29:02 -0700 (PDT) Message-ID: <54445747.1040806@gmail.com> Date: Sun, 19 Oct 2014 20:28:55 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" References: <20141020001405.32318.56727.idtracker@ietfa.amsl.com> In-Reply-To: <20141020001405.32318.56727.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141020001405.32318.56727.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/SCa3jKT6xdt-q21DzlcOQwGcX20 Cc: Spencer Dawkins Subject: [BEHAVE] Fwd: New Version Notification for draft-perrault-behave-deprecate-nat-mib-v1-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 00:29:06 -0000 I have submitted the I-D that deprecates the original NAT-MIB module. This required work on the introductory sections and the Security Considerations section. The MIB module itself is untouched from draft-ietf-behave-mib-11. I did run into a potential process issue: can't name the draft "draft-ietf-behave" because Behave is closed. Does that matter for AD-sponsored documents? Tom Taylor -------- Original Message -------- Subject: New Version Notification for draft-perrault-behave-deprecate-nat-mib-v1-00.txt Date: Sun, 19 Oct 2014 17:14:05 -0700 From: internet-drafts@ietf.org To: Tom Taylor , Senthil Sivakumar , Tina Tsou , Tina Tsou , Simon Perreault , Senthil Sivakumar , Tom Taylor , Simon Perreault A new version of I-D, draft-perrault-behave-deprecate-nat-mib-v1-00.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Name: draft-perrault-behave-deprecate-nat-mib-v1 Revision: 00 Title: Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT)) Document date: 2014-10-19 Group: Individual Submission Pages: 60 URL: http://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-00.txt Status: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ Htmlized: http://tools.ietf.org/html/draft-perrault-behave-deprecate-nat-mib-v1-00 Abstract: This memo deprecates MIB module NAT-MIB, a portion of the Management Information Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NAT-MIB-V2, which responds to deficiencies found in module NAT-MIB and adds new capabilities. This document obsoletes RFC 4008. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Oct 20 05:05:21 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D7D1A7035 for ; Mon, 20 Oct 2014 05:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 lEbIKzgXhDSq for ; Mon, 20 Oct 2014 05:05:13 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1671A86F8 for ; Mon, 20 Oct 2014 05:05:01 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so3785057lbi.9 for ; Mon, 20 Oct 2014 05:05:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ALSe5G9uIvCzYkm70Ia1H/PvEIM1wT8N/URuQ2CzQog=; b=fT6thHwLYm8E9O5gIjIx4tEC4hNmf9wMhzxB2EO4rVBKyuXw4J96kJXBAnWtwBX3Jh tlXPSE8MenPQGKk8mFq9rv5jh4KF2MegJjh2J8Cptkia8eVMbT9uuzxLs45K0Lndi4lh dq0k3/mwTZ15XRuJiNbjoqsrji+kflbQJonL32ENJkbfs0A4T71bT8MihJN3C6UxZMN3 An3NwOM4Ef6nxcxtfF3TfiCEoX+c0Qx4p+gGkhz57UtOwnVgUhmiJ7d3Hw4kFgUM5hT6 K9Rklo8UqAgJLmAkhErxoXktQfX0tPXIXMHIr5V+ozPXRhxQJXXnKhE8tskQuTqghuFq yEYg== X-Gm-Message-State: ALoCoQmrYHGWLl648g4xLud8oAPkDukZwon1i3487QiEVcq7mIw2pnvamvc9QG0MwG2dRN8zzia+ MIME-Version: 1.0 X-Received: by 10.152.9.201 with SMTP id c9mr26555182lab.38.1413806700117; Mon, 20 Oct 2014 05:05:00 -0700 (PDT) Received: by 10.25.137.9 with HTTP; Mon, 20 Oct 2014 05:05:00 -0700 (PDT) In-Reply-To: <54445747.1040806@gmail.com> References: <20141020001405.32318.56727.idtracker@ietfa.amsl.com> <54445747.1040806@gmail.com> Date: Mon, 20 Oct 2014 06:05:00 -0600 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a1132f75e2459360505d986af Archived-At: http://mailarchive.ietf.org/arch/msg/behave/mpkUpeHiFpi5rEP_411aoOYgMX8 Cc: "opsawg@ietf.org" , "behave@ietf.org" , Spencer Dawkins Subject: Re: [BEHAVE] [OPSAWG] Fwd: New Version Notification for draft-perrault-behave-deprecate-nat-mib-v1-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:05:14 -0000 --001a1132f75e2459360505d986af Content-Type: text/plain; charset=UTF-8 On Sun, Oct 19, 2014 at 6:28 PM, Tom Taylor wrote: > I have submitted the I-D that deprecates the original NAT-MIB module. This > required work on the introductory sections and the Security Considerations > section. Very good! > The MIB module itself is untouched from draft-ietf-behave-mib-11. Do you plan on modifying it? I would expect the only change to be the removal of new items defined in draft-ietf-behave-mib, correct? Simon --001a1132f75e2459360505d986af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Oct 19, 2014 at 6:28 PM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
I have submi= tted the I-D that deprecates the original NAT-MIB module. This required wor= k on the introductory sections and the Security Considerations section.

Very good!
=C2=A0
The MIB module itself is untouched from draft-ietf-behave= -mib-11.

Do you plan on modifying it? I wou= ld expect the only change to be the removal of new items defined in draft-i= etf-behave-mib, correct?

Simon=C2=A0
--001a1132f75e2459360505d986af-- From nobody Mon Oct 20 05:11:07 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981131A020B; Sat, 18 Oct 2014 12:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=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 AGmTYT0cg50H; Sat, 18 Oct 2014 12:46:00 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 501CE1A0069; Sat, 18 Oct 2014 12:46:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 59CD7825EF4; Sat, 18 Oct 2014 15:46:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBVK5EqYfd-n; Sat, 18 Oct 2014 15:46:05 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 23E78825EE7; Sat, 18 Oct 2014 15:46:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Scott O. Bradner" In-Reply-To: <5442C124.8070904@gmail.com> Date: Sat, 18 Oct 2014 15:45:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5442C124.8070904@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/behave/DNjUUrjU_0aO-4gpz5XGzaWXyXM X-Mailman-Approved-At: Mon, 20 Oct 2014 05:11:05 -0700 Cc: draft-ietf-behave-mib.authors@tools.ietf.org, "opsawg@ietf.org" , "behave@ietf.org" , Spencer Dawkins Subject: Re: [BEHAVE] [OPSAWG] Splitting of draft-ietf-behave-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 19:46:01 -0000 sounds cleaner Scott On Oct 18, 2014, at 3:36 PM, Tom Taylor = wrote: > draft-ietf-behave-mib = (http://tools.ietf.org/html/draft-ietf-behave-nat-mib) has been = undergoing AD-sponsored process. I have completed setting up an issue = tracker based on the issues raised in the Behave Trac tickets #16-19 and = the 45 comments generated by David Harrington in his detailed review. = The entry point to that issuee tracker is at >=20 > http://trac.tools.ietf.org/wg/behave/trac/wiki/PostIssueTracker >=20 > One of the issues was procedural. The current draft deprecates all of = the objects in the original NAT MIB module (RFC 4008) and then goes on = to define new objects using the same MIB module name. There seems to be = agreement that instead, there will be one I-D for the deprecation of = NAT-MIB and a second I-D to define NAT-MIB-V2. RFC 4008 will be declared = Historic. >=20 > Do I have the procedure right, and are there any other comments? >=20 > Tom Taylor >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Oct 20 05:11:08 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB891A1A74; Sun, 19 Oct 2014 17:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=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 S9E2_VDuNSni; Sun, 19 Oct 2014 17:41:14 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id CBB491A1A65; Sun, 19 Oct 2014 17:41:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 681D0837CB2; Sun, 19 Oct 2014 20:41:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPl0sIelBQsG; Sun, 19 Oct 2014 20:41:20 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id B5F82837C95; Sun, 19 Oct 2014 20:41:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Scott O. Bradner" In-Reply-To: <54445747.1040806@gmail.com> Date: Sun, 19 Oct 2014 20:40:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141020001405.32318.56727.idtracker@ietfa.amsl.com> <54445747.1040806@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/behave/eMWVq6xy6xPVwLAIOMSm7Ja4yns X-Mailman-Approved-At: Mon, 20 Oct 2014 05:11:05 -0700 Cc: "opsawg@ietf.org" , "behave@ietf.org" , Spencer Dawkins Subject: Re: [BEHAVE] [OPSAWG] New Version Notification for draft-perrault-behave-deprecate-nat-mib-v1-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 00:41:17 -0000 the draft file name has not historically mattered for AD sponsored = documents=20 (unless the name is obscene :-) ) Scott On Oct 19, 2014, at 8:28 PM, Tom Taylor = wrote: > I have submitted the I-D that deprecates the original NAT-MIB module. = This required work on the introductory sections and the Security = Considerations section. The MIB module itself is untouched from = draft-ietf-behave-mib-11. >=20 > I did run into a potential process issue: can't name the draft = "draft-ietf-behave" because Behave is closed. Does that matter for = AD-sponsored documents? >=20 > Tom Taylor >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-perrault-behave-deprecate-nat-mib-v1-00.txt > Date: Sun, 19 Oct 2014 17:14:05 -0700 > From: internet-drafts@ietf.org > To: Tom Taylor , Senthil Sivakumar = , Tina Tsou , Tina = Tsou , Simon Perreault = , Senthil Sivakumar , = Tom Taylor , Simon Perreault = >=20 >=20 > A new version of I-D, = draft-perrault-behave-deprecate-nat-mib-v1-00.txt > has been successfully submitted by Tom Taylor and posted to the > IETF repository. >=20 > Name: draft-perrault-behave-deprecate-nat-mib-v1 > Revision: 00 > Title: Deprecation of MIB Module NAT-MIB (Managed = Objects for Network Address Translators (NAT)) > Document date: 2014-10-19 > Group: Individual Submission > Pages: 60 > URL: = http://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mi= b-v1-00.txt > Status: = https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v= 1/ > Htmlized: = http://tools.ietf.org/html/draft-perrault-behave-deprecate-nat-mib-v1-00 >=20 >=20 > Abstract: > This memo deprecates MIB module NAT-MIB, a portion of the Management > Information Base (MIB) previously defined in RFC 4008 for devices > implementing Network Address Translator (NAT) function. A companion > document defines a new version, NAT-MIB-V2, which responds to > deficiencies found in module NAT-MIB and adds new capabilities. >=20 > This document obsoletes RFC 4008. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Oct 20 05:49:15 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEC81A8722; Mon, 20 Oct 2014 05:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 HHN7C_xyCamj; Mon, 20 Oct 2014 05:49:12 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C205E1A8711; Mon, 20 Oct 2014 05:49:12 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id hn15so4468155igb.9 for ; Mon, 20 Oct 2014 05:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/Sr7X9b+22sfnxlkWe9wbCBfIgBK/nC1FksZx8MLq28=; b=dnzSnbpBqsYjD8vrc5IN0T3SWQwSybc6qZCAIoPyCy1Fwjn7kKEURTQruw41JUjPAn O9ZvlSSSHzyh55FjrKuxi/ZXUpSoeJ/ceWQxcJEQ1koXQfP5UKVdG+ImDM5SFFnr+YZ3 gsGXwfSJR6+BqWza+3tPGZbZ0rcvqHnNNzvFJPIVvq10nq+DqSbgp30J7przcCMzeDd9 fvpfU0g2Ou4WK5rcmyuafAlYIIT1iQoBE64JL0/EmQWGfNa9oSk46Yqs2y8Tj+UCS11O d7ITk5RywGkIMEFR6sBgrS1bMaKiPZjHvtsCrGsFmVqRuIA13QIN2UXl4zzNi7LCa/cF bdKA== X-Received: by 10.107.10.193 with SMTP id 62mr2325317iok.64.1413809349225; Mon, 20 Oct 2014 05:49:09 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-34-155.tor.primus.ca. [173.206.34.155]) by mx.google.com with ESMTPSA id f41sm4473793ioj.8.2014.10.20.05.49.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 05:49:08 -0700 (PDT) Message-ID: <544504BE.5070306@gmail.com> Date: Mon, 20 Oct 2014 08:49:02 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <20141020001405.32318.56727.idtracker@ietfa.amsl.com> <54445747.1040806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/DYPxCyIuLeR33U649fpjBnuYYtI Cc: "opsawg@ietf.org" , "behave@ietf.org" , Spencer Dawkins Subject: Re: [BEHAVE] [OPSAWG] Fwd: New Version Notification for draft-perrault-behave-deprecate-nat-mib-v1-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:49:14 -0000 On 20/10/2014 8:05 AM, Simon Perreault wrote: > On Sun, Oct 19, 2014 at 6:28 PM, Tom Taylor > wrote: > >> I have submitted the I-D that deprecates the original NAT-MIB module. This >> required work on the introductory sections and the Security Considerations >> section. > > > Very good! > > >> The MIB module itself is untouched from draft-ietf-behave-mib-11. > > > Do you plan on modifying it? I would expect the only change to be the > removal of new items defined in draft-ietf-behave-mib, correct? > > Simon > That`s correct. Tom From nobody Mon Oct 20 09:55:23 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE531A8729; Mon, 20 Oct 2014 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 oZbMTlDo8C-P; Mon, 20 Oct 2014 09:55:19 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A501A87C6; Mon, 20 Oct 2014 09:40:56 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so4208394lbv.19 for ; Mon, 20 Oct 2014 09:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TvmrImF7+1d8rE3ldrwlEoSXev+AbFnDSzvYyvsYytI=; b=aTj3O7kPWI47kcqMj48k8bebQYOwyhTz+MFAKLwhnFNHseRbINC6Fg33cCk6Z0EqwB HI+yIj3cGyBrPA2sEgNFxK5HzYcJE/jXzsQwjw1ipHrHfb0b+eTldb8XhxMEKsycFtJm +srm6FSlcmom9Lz/qkUF0MWZ+d/qpZkD8c58XcGXjIZmB/hTbHGFHcqlANM4U59aFMSH W0/kfzmy0hSknc6WFbGo2Nv228skHsgi3Aj5FDHOZ+D7q5tO5ukpXfOrltgvU3VnPOc3 kry8tMJ/gtRbQm7hdnUCXU5/oBB5yN+bJs0sj0vv5ELPwuwXenz7qQl5oYp5ztSyh54z TueQ== MIME-Version: 1.0 X-Received: by 10.152.206.36 with SMTP id ll4mr29182785lac.64.1413823254668; Mon, 20 Oct 2014 09:40:54 -0700 (PDT) Received: by 10.152.182.171 with HTTP; Mon, 20 Oct 2014 09:40:54 -0700 (PDT) In-Reply-To: References: <20141020001405.32318.56727.idtracker@ietfa.amsl.com> <54445747.1040806@gmail.com> Date: Mon, 20 Oct 2014 11:40:54 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Scott O. Bradner" Content-Type: multipart/alternative; boundary=001a1133b742dea9b40505dd60f4 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/qVten7yPgYnqXdYhlcNnTKtsv2Y Cc: "opsawg@ietf.org" , "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] [OPSAWG] New Version Notification for draft-perrault-behave-deprecate-nat-mib-v1-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:55:21 -0000 --001a1133b742dea9b40505dd60f4 Content-Type: text/plain; charset=UTF-8 Tom, On Sun, Oct 19, 2014 at 7:40 PM, Scott O. Bradner wrote: > the draft file name has not historically mattered for AD sponsored > documents > (unless the name is obscene :-) ) > > Scott > > On Oct 19, 2014, at 8:28 PM, Tom Taylor wrote: > > > I have submitted the I-D that deprecates the original NAT-MIB module. > This required work on the introductory sections and the Security > Considerations section. The MIB module itself is untouched from > draft-ietf-behave-mib-11. > > > > I did run into a potential process issue: can't name the draft > "draft-ietf-behave" because Behave is closed. Does that matter for > AD-sponsored documents? > > > > Tom Taylor > I think an individual name format would be right. And I don't expect you'll have a problem thinking of one that's not obscene :-) Spencer > > -------- Original Message -------- > > Subject: New Version Notification for > draft-perrault-behave-deprecate-nat-mib-v1-00.txt > > Date: Sun, 19 Oct 2014 17:14:05 -0700 > > From: internet-drafts@ietf.org > > To: Tom Taylor , Senthil Sivakumar < > ssenthil@cisco.com>, Tina Tsou , Tina Tsou < > tina.tsou.zouting@huawei.com>, Simon Perreault < > simon.perreault@viagenie.ca>, Senthil Sivakumar , Tom > Taylor , Simon Perreault < > simon.perreault@viagenie.ca> > > > > > > A new version of I-D, draft-perrault-behave-deprecate-nat-mib-v1-00.txt > > has been successfully submitted by Tom Taylor and posted to the > > IETF repository. > > > > Name: draft-perrault-behave-deprecate-nat-mib-v1 > > Revision: 00 > > Title: Deprecation of MIB Module NAT-MIB (Managed Objects > for Network Address Translators (NAT)) > > Document date: 2014-10-19 > > Group: Individual Submission > > Pages: 60 > > URL: > http://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ > > Htmlized: > http://tools.ietf.org/html/draft-perrault-behave-deprecate-nat-mib-v1-00 > > > > > > Abstract: > > This memo deprecates MIB module NAT-MIB, a portion of the Management > > Information Base (MIB) previously defined in RFC 4008 for devices > > implementing Network Address Translator (NAT) function. A companion > > document defines a new version, NAT-MIB-V2, which responds to > > deficiencies found in module NAT-MIB and adds new capabilities. > > > > This document obsoletes RFC 4008. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > --001a1133b742dea9b40505dd60f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tom,

On Sun, Oct 19, 2014 at 7:40 PM, Scott O. Bradner <sob@sobco.= com> wrote:
the draft file = name has not historically mattered for AD sponsored documents
(unless the name is obscene :-) )

Scott

On Oct 19, 2014, at 8:28 PM, Tom Taylor <tom.taylor.stds@gmail.com> wrote:

> I have submitted the I-D that deprecates the original NAT-MIB module. = This required work on the introductory sections and the Security Considerat= ions section. The MIB module itself is untouched from draft-ietf-behave-mib= -11.
>
> I did run into a potential process issue: can't name the draft &qu= ot;draft-ietf-behave" because Behave is closed. Does that matter for A= D-sponsored documents?
>
> Tom Taylor

I think an = individual name format would be right. And I don't expect you'll ha= ve a problem thinking of one that's not obscene :-)

Spencer=C2=A0
=C2=A0
> -------- Original Message --------
> Subject: New Version Notification for draft-perrault-behave-deprecate-= nat-mib-v1-00.txt
> Date: Sun, 19 Oct 2014 17:14:05 -0700
> From: internet-drafts@ietf= .org
> To: Tom Taylor <tom.ta= ylor.stds@gmail.com>, Senthil Sivakumar <ssenthil@cisco.com>, Tina Tsou <tina.tsou.zouting@huawei.com>, Tina Tso= u <tina.tsou.zouting@hua= wei.com>, Simon Perreault <simon.perreault@viagenie.ca>, Senthil Sivakumar <ssenthil@cisco.com>, Tom Taylor <<= a href=3D"mailto:tom.taylor.stds@gmail.com">tom.taylor.stds@gmail.com&g= t;, Simon Perreault <simo= n.perreault@viagenie.ca>
>
>
> A new version of I-D, draft-perrault-behave-deprecate-nat-mib-v1-00.tx= t
> has been successfully submitted by Tom Taylor and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-perrault-behave-deprecate= -nat-mib-v1
> Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecat= ion of MIB Module NAT-MIB (Managed Objects for Network Address Translators = (NAT))
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2014-10-19
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 60
> URL: http://www.ietf.org/inte= rnet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-00.txt
> Status: https://datatracker.ietf.org/d= oc/draft-perrault-behave-deprecate-nat-mib-v1/
> Htmlized: http://tools.ietf.org/html/draft= -perrault-behave-deprecate-nat-mib-v1-00
>
>
> Abstract:
>=C2=A0 =C2=A0This memo deprecates MIB module NAT-MIB, a portion of the = Management
>=C2=A0 =C2=A0Information Base (MIB) previously defined in RFC 4008 for = devices
>=C2=A0 =C2=A0implementing Network Address Translator (NAT) function.=C2= =A0 A companion
>=C2=A0 =C2=A0document defines a new version, NAT-MIB-V2, which responds= to
>=C2=A0 =C2=A0deficiencies found in module NAT-MIB and adds new capabili= ties.
>
>=C2=A0 =C2=A0This document obsoletes RFC 4008.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


--001a1133b742dea9b40505dd60f4-- From nobody Thu Oct 23 03:12:56 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EC01A8A4D for ; Thu, 23 Oct 2014 03:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 oQIicY5JN3Xx for ; Thu, 23 Oct 2014 03:12:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 49AD21A8A47 for ; Thu, 23 Oct 2014 03:12:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6E301181C71; Thu, 23 Oct 2014 03:12:25 -0700 (PDT) To: rohan@ekabal.com, philip_matthews@magma.ca, jdrosen@jdrosen.net, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, dwing@cisco.com, dthaler@microsoft.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141023101225.6E301181C71@rfc-editor.org> Date: Thu, 23 Oct 2014 03:12:25 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/behave/AVHkI0sSpCpdz4XO6Lx7Ueet4Bc Cc: ignatiomobius@gmail.com, behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Editorial Errata Reported] RFC5766 (4143) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 10:12:54 -0000 The following errata report has been submitted for RFC5766, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5766&eid=4143 -------------------------------------- Type: Editorial Reported by: Florian Waltersdorfer Section: 1.Intro... Original Text ------------- attempt discover a direct communication path; that is, a Corrected Text -------------- attempt to discover a direct communication path; that is, a Notes ----- line 177 in the txt version, attempt *to* do something Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5766 (draft-ietf-behave-turn-16) -------------------------------------- Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Publication Date : April 2010 Author(s) : R. Mahy, P. Matthews, J. Rosenberg Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From nobody Thu Oct 23 19:53:19 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9541A885A for ; Thu, 23 Oct 2014 19:53:18 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 sE-fCJ0gRZoc for ; Thu, 23 Oct 2014 19:53:17 -0700 (PDT) Received: from mail-07.primus.ca (smtp1.primus.ca [209.216.129.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCAA1A883C for ; Thu, 23 Oct 2014 19:53:16 -0700 (PDT) Received: from bas2-kanata16-2925497756.dsl.bell.ca ([174.95.141.156] helo=[10.0.2.3]) by mail-07.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1XhUzz-0006cW-2f; Thu, 23 Oct 2014 22:53:08 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20141023101225.6E301181C71@rfc-editor.org> Date: Thu, 23 Oct 2014 22:53:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3C1B6706-F573-4835-9B44-50D77269C52F@magma.ca> References: <20141023101225.6E301181C71@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas2-kanata16-2925497756.dsl.bell.ca ([10.0.2.3]) [174.95.141.156] Archived-At: http://mailarchive.ietf.org/arch/msg/behave/65Xg3w1INYcKFpKXQSdvDbi6Ak8 Cc: rohan@ekabal.com, behave@ietf.org, jdrosen@jdrosen.net, dthaler@microsoft.com, mls.ietf@gmail.com, spencerdawkins.ietf@gmail.com, dwing@cisco.com, ignatiomobius@gmail.com Subject: Re: [BEHAVE] [Editorial Errata Reported] RFC5766 (4143) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 02:53:18 -0000 Looks valid to me. I have already forwarded it to Alan Johnson who is working on the = turn-bis document. Philip On 2014-10-23, at 6:12 , RFC Errata System wrote: > The following errata report has been submitted for RFC5766, > "Traversal Using Relays around NAT (TURN): Relay Extensions to Session = Traversal Utilities for NAT (STUN)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5766&eid=3D4143 >=20 > -------------------------------------- > Type: Editorial > Reported by: Florian Waltersdorfer >=20 > Section: 1.Intro... >=20 > Original Text > ------------- > attempt discover a direct communication path; that is, a >=20 > Corrected Text > -------------- > attempt to discover a direct communication path; that is, a >=20 > Notes > ----- > line 177 in the txt version, attempt *to* do something >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5766 (draft-ietf-behave-turn-16) > -------------------------------------- > Title : Traversal Using Relays around NAT (TURN): Relay = Extensions to Session Traversal Utilities for NAT (STUN) > Publication Date : April 2010 > Author(s) : R. Mahy, P. Matthews, J. Rosenberg > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 >=20 From nobody Sun Oct 26 15:35:41 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1140A1A1AE6; Sun, 26 Oct 2014 15:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 lK2Fbg36-Szw; Sun, 26 Oct 2014 15:35:34 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E545C1A1AE4; Sun, 26 Oct 2014 15:35:33 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id r10so2932166igi.0 for ; Sun, 26 Oct 2014 15:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=kj90dUtiPB1r1kjo4ZnVblzJUOzw/bPfzdmoOd3KbO4=; b=BBdr7ULXiWVYl0AFt99PwhZ6tdZSlV8efAqedFt1FIXvJFjbCqHw1cviwCQeCorbyy A4ndL1rxoDo+S0wGVYYy6zU4aqIq0bnIN/2fXDJsbgEn4leRMqYwRXZlCV2oFRdnQnt+ OIJDoyFskI00HvxGSn/GbM9E2qLwWkVURoTJRoUCO9M+xKB31MYT/iqGu9h7pEr5+ukL a0diadzUGcjtf5OgPRUy//k6ACY6n2p6rWrLfuIFtViFs3ZVqoLVqGFHa1vMLKEyM+M8 6KUKLdfKaTyAXFqSaku94mw1fIqTX+4kAj2wbBSDFfQpOUp4O3D4mYFjSICwJAscDUVA 5olA== X-Received: by 10.107.167.66 with SMTP id q63mr18529929ioe.23.1414362933285; Sun, 26 Oct 2014 15:35:33 -0700 (PDT) Received: from [192.168.0.102] ([216.254.166.33]) by mx.google.com with ESMTPSA id 8sm4117046igy.0.2014.10.26.15.35.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 15:35:33 -0700 (PDT) Message-ID: <544D772F.6060009@gmail.com> Date: Sun, 26 Oct 2014 18:35:27 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/oNBYFax211LZ8gKv-l6HfX-CZo4 Subject: [BEHAVE] Major NAT MIB Issue: Notifications and processor requirements at the agent X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 22:35:36 -0000 A little terminology to start with: 1) A realm defines an addressing space. Simple NATs may support just two realms: internal and external. This is all that RFC 4008 supports. In more complex situations the NAT will support several or many realms. Individual realms in that case can be internal from the point of view of some hosts served by the NAT and external from the point of view of others. 2) An address mapping is an assignment of an address in a selected external realm to the address of a host in its internal realm. 3) An address and port mapping is a mapping between the address and port of a host in its internal realm for a given protocol to an address and port in a selected external realm. For mappings triggered by packets outgoing from the internal host, the external realm is selected based on the packet destination. For mappings triggered by packets incoming from an external realm, the external realm is the one from which the packet originated. 4) An address pool is a separately-managed set of addresses and ports/ICMP identifiers in a particular realm, available for assignment to the 'external' portion of a mapping. Pools can be used to ration the available external addresses to different realms and classes of subscribers. Where more than one pool has been assigned to the realm, policy determines which subscribers and/or services are mapped to which pool. The NAT MIB (draft-ietf-behave-nat-mib-11) currently has five notifications, which can be enabled and disabled through their respective threshold settings: - Address pool low threshold undershot -- reports under-utilization of an address pool - Address pool high threshold exceeded -- reports potential over-utilization of an address pool - Address mapping threshold exceeded -- reports potential exhaustion of addresses for the NAT instance as a whole - Address and port mapping threshold exceeded -- reports potential exhaustion of address plus port combinations for the NAT instance as a whole - Per-subscriber address and port mapping threshold exceeded -- can be used for troubleshooting (enabled for specific subscriber) or provisioning (enabled for all subscribers) Just as a preliminary, my personal view is that the notification relating to low pool utilization should not be there, and if the information is needed, it should be handled by the management application. Hence this one should be omitted from the discussion which follows. David Harrington in his review was concerned that these notifications involved calculations at the agent that were excessively demanding of processor capacity. This is especially true of the MIB's current algorithm for address pool utilization. More on that in a moment. Just for background, the MIB supports the following read-write hard limits, beyond which incoming packets are dropped rather than translated: - Maximum number of active address mappings - Maximum number of active address and port mappings - Maximum number of fragments awaiting reassembly - Maximum number of subscribers with active address and port mappings The resources that need monitoring in the NAT are NAT memory, address pool utilization, and processor capacity. The only item in the above list of notifications and limits that at least partially addresses processor capacity is the last limit, on number of active subscribers. Possibly, a notification and limit could be introduced based on the rate of change of the number of active mappings. The problem with NAT pool monitoring is that the pool actually contains two resources, addresses and ports, and how they get used up depends on RFC 4787 pooling behaviour. For the RECOMMENDED pooling behaviour of 'paired', port exhaustion occurs when all the ports for the desired protocol available to the subscriber on a mapped external address are used up, the NAT cannot (for reasons of policy or availability) assign additional ports to that subscriber on that same address, and the NAT cannot assign an additional address containing free ports to that subscriber. (This last condition is subject to discussion: is it port exhaustion or address exhaustion?) For a pooling behaviour of 'arbitrary', port exhaustion occurs when there is no available port for the desired protocol at any of the addresses in the pool. Clearly port exhaustion will be a rarer event in the 'arbitrary' case. draft-ietf-behave-nat-mib-11 triggers notifications based on the ratio of active address and port mappings using a given pool to the total number of address-port combinations made available by the pool, expressed as a percentage. As David Harrington pointed out, this makes a lot of demands on the agent processor. We have some alternatives: 1) No notification: leave any processing to the management application. 2) Trigger the high usage notification based on the rate of occurrence of out-of-port events, with the same threshold value for all pools. This is reasonably valid statistically for a low threshold (i.e., taking the view that any port exhaustion at all is actionable), but not terribly reliable in the 'paired' case, in that a single subscriber can dominate the results. 3) Trigger the high usage notification based on the rate of occurrence of out-of-port events, with a higher threshold value based on pool size (addresses x ports) and sharing ratio. This requires some mathematical analysis and per-pool configuration. What do people recommend? Tom Taylor From nobody Mon Oct 27 06:36:06 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DEF1AC7E7 for ; Mon, 27 Oct 2014 06:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 VkHYd0hzeJpU for ; Mon, 27 Oct 2014 06:35:36 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011D81A903F for ; Mon, 27 Oct 2014 06:35:35 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so5619640lbd.6 for ; Mon, 27 Oct 2014 06:35:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lSVRXjAc63gFdRh4hr/C1VJEHk1ot0HM44bqfBbidIY=; b=CMDA60UCrezC2yoq1WSoneDFFALM3hRnkmiYA+xf3IPHSvReb8Wk4jMceZE6/sPyRW fdhO/RrwdddUdouH7tEcNvcPyFxBPbUFp3zLQPtjq+/A5hOgesEKxglHPZa67JTspaXd Pra+uYI2Ru7i5PNNtSFsmRYL81ydXQwnhz369VXA5+mv+W4WwMb6hFHMnBlvVi7F9Af2 WhX5QYmNSvAqcn1QIM4toZRC/FULfjUctOOMSXe4qmP3O2JCOqIBEJACOSPRfjjSXla4 o20yIqN5dTFrGdU64xWwEikADlKp8dGJsVc+akuiNcLWm8DIT4adm75hIGyy6CKeABVf sm9g== X-Gm-Message-State: ALoCoQlf4QgMyXT3YpFErhU6uYBTZli5GMlddJSPwjYi0elJ2IaAY5vToa3rtHcxCsGYR05kBIbv MIME-Version: 1.0 X-Received: by 10.152.9.201 with SMTP id c9mr23428467lab.38.1414416933777; Mon, 27 Oct 2014 06:35:33 -0700 (PDT) Received: by 10.25.167.20 with HTTP; Mon, 27 Oct 2014 06:35:33 -0700 (PDT) In-Reply-To: <544D772F.6060009@gmail.com> References: <544D772F.6060009@gmail.com> Date: Mon, 27 Oct 2014 09:35:33 -0400 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a1132f75ee70aa40506679a39 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/QmBjXxEHnSEntZvnm9AcNn1xxnU Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 13:35:44 -0000 --001a1132f75ee70aa40506679a39 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 26, 2014 at 6:35 PM, Tom Taylor wrote: > A little terminology to start with: > > 1) A realm defines an addressing space. Simple NATs may support just two > realms: internal and external. This is all that RFC 4008 supports. In more > complex situations the NAT will support several or many realms. Individual > realms in that case can be internal from the point of view of some hosts > served by the NAT and external from the point of view of others. > > 2) An address mapping is an assignment of an address in a selected > external realm to the address of a host in its internal realm. > > 3) An address and port mapping is a mapping between the address and port > of a host in its internal realm for a given protocol to an address and port > in a selected external realm. For mappings triggered by packets outgoing > from the internal host, the external realm is selected based on the packet > destination. > While this is often true in practice, in theory the NAT could pick the external realm based on whatever arbitrary rule with which it is configured. For example, software NATs (e.g., Linux's Netfilter) allow a lot of flexibility here. > For mappings triggered by packets incoming from an external realm, the > external realm is the one from which the packet originated. > > 4) An address pool is a separately-managed set of addresses and ports/ICMP > identifiers in a particular realm, available for assignment to the > 'external' portion of a mapping. Pools can be used to ration the available > external addresses to different realms and classes of subscribers. Where > more than one pool has been assigned to the realm, policy determines which > subscribers and/or services are mapped to which pool. > > > The NAT MIB (draft-ietf-behave-nat-mib-11) currently has five > notifications, which can be enabled and disabled through their respective > threshold settings: > > - Address pool low threshold undershot > -- reports under-utilization of an address pool > > - Address pool high threshold exceeded > -- reports potential over-utilization of an address pool > > - Address mapping threshold exceeded > -- reports potential exhaustion of addresses > for the NAT instance as a whole > > - Address and port mapping threshold exceeded > -- reports potential exhaustion of address plus port > combinations for the NAT instance as a whole > > - Per-subscriber address and port mapping threshold exceeded > -- can be used for troubleshooting (enabled for specific > subscriber) or provisioning (enabled for all subscribers) > > Just as a preliminary, my personal view is that the notification relating > to low pool utilization should not be there, and if the information is > needed, it should be handled by the management application. Hence this one > should be omitted from the discussion which follows. > Yes, I agree that that can work in practice. However I don't see the difference in reasoning between this notification and the others. Couldn't the others also be handled by the management application? David Harrington in his review was concerned that these notifications > involved calculations at the agent that were excessively demanding of > processor capacity. This is especially true of the MIB's current algorithm > for address pool utilization. More on that in a moment. > > Just for background, the MIB supports the following read-write hard > limits, beyond which incoming packets are dropped rather than translated: > > - Maximum number of active address mappings > - Maximum number of active address and port mappings > - Maximum number of fragments awaiting reassembly > - Maximum number of subscribers with active address and port mappings > > The resources that need monitoring in the NAT are NAT memory, address pool > utilization, and processor capacity. The only item in the above list of > notifications and limits that at least partially addresses processor > capacity is the last limit, on number of active subscribers. Possibly, a > notification and limit could be introduced based on the rate of change of > the number of active mappings. > Agreed. And such rate-limiting is required for CGNs per REQ-4-c and REQ-5-b from RFC6888: c. Additionally, it is RECOMMENDED that the CGN include administrator-adjustable thresholds to prevent a single subscriber from consuming excessive CPU resources from the CGN (e.g., rate-limit the subscriber's creation of new mappings). [...] b. Additionally, it SHOULD be possible to limit the rate at which memory-consuming state elements are allocated. The problem with NAT pool monitoring is that the pool actually contains two > resources, addresses and ports, and how they get used up depends on RFC > 4787 pooling behaviour. > Well, yes, but I don't see how this is a problem. Keep in mind that some NATs don't bother with ports and allocate full addresses. That is supported with the current pool and mapping models. For the RECOMMENDED pooling behaviour of 'paired', port exhaustion occurs > when all the ports for the desired protocol available to the subscriber on > a mapped external address are used up, the NAT cannot (for reasons of > policy or availability) assign additional ports to that subscriber on that > same address, and the NAT cannot assign an additional address containing > free ports to that subscriber. (This last condition is subject to > discussion: is it port exhaustion or address exhaustion?) > It depends on what you mean by "cannot". A "paired" NAT may decide to allocate a mapping from any other available address and not even consider this an exhaustion condition. It may decide to replace the current address mapping with this new address. Or it may consider this a "temporary address mapping" to be reverted eventually. Or it may not record this new mapping at all, and just allocate mappings from any random address as long as the primary address is exhausted. Or it may refuse to create a new mapping, as you seem to imply. We should not "think" too much about NAT implementation... What matters is observable behaviour, and in particular observable behaviour that is general enough that it can be usefully modelled in a MIB. Whatever triggers an exhaustion event is not absolutely important. We just need to be able to report it. It will be up to the NAT administrator to determine, based on the particular NAT implementation, what exactly exhaustion means. Some NATs are very configurable in this matter. For a pooling behaviour of 'arbitrary', port exhaustion occurs when there > is no available port for the desired protocol at any of the addresses in > the pool. Clearly port exhaustion will be a rarer event in the 'arbitrary' > case. > Again, it depends on the implementation. draft-ietf-behave-nat-mib-11 triggers notifications based on the ratio of > active address and port mappings using a given pool to the total number of > address-port combinations made available by the pool, expressed as a > percentage. As David Harrington pointed out, this makes a lot of demands on > the agent processor. We have some alternatives: > > 1) No notification: leave any processing to the management application. > The problem with this is that the management application would effectively have to bulk fetch the full mapping table to be able to compute pool usage. That could be much more taxing on the agent than computing pool usage by itself. 2) Trigger the high usage notification based on the rate of occurrence of > out-of-port events, with the same threshold value for all pools. This is > reasonably valid statistically for a low threshold (i.e., taking the view > that any port exhaustion at all is actionable), but not terribly reliable > in the 'paired' case, in that a single subscriber can dominate the results. > > 3) Trigger the high usage notification based on the rate of occurrence of > out-of-port events, with a higher threshold value based on pool size > (addresses x ports) and sharing ratio. This requires some mathematical > analysis and per-pool configuration. > I think these two options are non-starters because they rely on heuristics rather than hard metrics. Plus, maintaining a "rate of occurence" is not much less involved than computing pool usage in the first place. Suggestion: We need to see what current NATs report, especially CGNs. For many vendors the documentation is public... Simon --001a1132f75ee70aa40506679a39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Oct 26, 2014 at 6:35 PM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
A little terminology to start with:

1) A realm defines an addressing space. Simple NATs may support just two re= alms: internal and external. This is all that RFC 4008 supports. In more co= mplex situations the NAT will support several or many realms. Individual re= alms in that case can be internal from the point of view of some hosts serv= ed by the NAT and external from the point of view of others.

2) An address mapping is an assignment of an address in a selected external= realm to the address of a host in its internal realm.

3) An address and port mapping is a mapping between the address and port of= a host in its internal realm for a given protocol to an address and port i= n a selected external realm. For mappings triggered by packets outgoing fro= m the internal host, the external realm is selected based on the packet des= tination.

While this is often true in= practice, in theory the NAT could pick the external realm based on whateve= r arbitrary rule with which it is configured. For example, software NATs (e= .g., Linux's Netfilter) allow a lot of flexibility here.
=C2= =A0
For mappings triggered by packets incoming from an external realm, th= e external realm is the one from which the packet originated.

4) An address pool is a separately-managed set of addresses and ports/ICMP = identifiers in a particular realm, available for assignment to the 'ext= ernal' portion of a mapping. Pools can be used to ration the available = external addresses to different realms and classes of subscribers. Where mo= re than one pool has been assigned to the realm, policy determines which su= bscribers and/or services are mapped to which pool.


The NAT MIB (draft-ietf-behave-nat-mib-11) currently has five notifications= , which can be enabled and disabled through their respective threshold sett= ings:

- Address pool low threshold undershot
=C2=A0 -- reports under-utilization of an address pool

- Address pool high threshold exceeded
=C2=A0 -- reports potential over-utilization of an address pool

- Address mapping threshold exceeded
=C2=A0 -- reports potential exhaustion of addresses
=C2=A0 =C2=A0 =C2=A0for the NAT instance as a whole

- Address and port mapping threshold exceeded
=C2=A0 -- reports potential exhaustion of address plus port
=C2=A0 =C2=A0 =C2=A0combinations for the NAT instance as a whole

- Per-subscriber address and port mapping threshold exceeded
=C2=A0 -- can be used for troubleshooting (enabled for specific
=C2=A0 =C2=A0 =C2=A0subscriber) or provisioning (enabled for all subscriber= s)

Just as a preliminary, my personal view is that the notification relating t= o low pool utilization should not be there, and if the information is neede= d, it should be handled by the management application. Hence this one shoul= d be omitted from the discussion which follows.
=
Yes, I agree that that can work in practice. However I don&#= 39;t see the difference in reasoning between this notification and the othe= rs. Couldn't the others also be handled by the management application?<= /div>

David Harrington in his review was concerned that these notifications invol= ved calculations at the agent that were excessively demanding of processor = capacity. This is especially true of the MIB's current algorithm for ad= dress pool utilization. More on that in a moment.

Just for background, the MIB supports the following read-write hard limits,= beyond which incoming packets are dropped rather than translated:

- Maximum number of active address mappings
- Maximum number of active address and port mappings
- Maximum number of fragments awaiting reassembly
- Maximum number of subscribers with active address and port mappings

The resources that need monitoring in the NAT are NAT memory, address pool = utilization, and processor capacity. The only item in the above list of not= ifications and limits that at least partially addresses processor capacity = is the last limit, on number of active subscribers. Possibly, a notificatio= n and limit could be introduced based on the rate of change of the number o= f active mappings.

Agreed. And su= ch rate-limiting is required for CGNs per REQ-4-c and REQ-5-b from RFC6888:= 

      c.  Additionally, it is RECO=
MMENDED that the CGN include
          administrator-adjustable thresholds to prevent a single
          subscriber from consuming excessive CPU resources from the CGN
          (e.g., rate-limit the subscriber's creation of new mappings).=


[...]
      b.  Additionally, it SHOULD be possible to limit =
the rate at which
          memory-consuming state elements are allocated.
<= div>
The problem with NAT pool monitoring is that the pool actually contains two= resources, addresses and ports, and how they get used up depends on RFC 47= 87 pooling behaviour.

Well, yes, = but I don't see how this is a problem.

Keep in= mind that some NATs don't bother with ports and allocate full addresse= s. That is supported with the current pool and mapping models.
For the RECOMMENDED pooling behaviour of 'paired', port exhaustion = occurs when all the ports for the desired protocol available to the subscri= ber on a mapped external address are used up, the NAT cannot (for reasons o= f policy or availability) assign additional ports to that subscriber on tha= t same address, and the NAT cannot assign an additional address containing = free ports to that subscriber. (This last condition is subject to discussio= n: is it port exhaustion or address exhaustion?)

It depends on what you mean by "cannot". A "= paired" NAT may decide to allocate a mapping from any other available = address and not even consider this an exhaustion condition. It may decide t= o replace the current address mapping with this new address. Or it may cons= ider this a "temporary address mapping" to be reverted eventually= . Or it may not record this new mapping at all, and just allocate mappings = from any random address as long as the primary address is exhausted. Or it = may refuse to create a new mapping, as you seem to imply.

We should not "think" too much about NAT implementation..= . What matters is observable behaviour, and in particular observable behavi= our that is general enough that it can be usefully modelled in a MIB. Whate= ver triggers an exhaustion event is not absolutely important. We just need = to be able to report it. It will be up to the NAT administrator to determin= e, based on the particular NAT implementation, what exactly exhaustion mean= s. Some NATs are very configurable in this matter.

For a pooling behaviour of 'arbitrary', port exhaustion occurs when= there is no available port for the desired protocol at any of the addresse= s in the pool. Clearly port exhaustion will be a rarer event in the 'ar= bitrary' case.

Again, it depe= nds on the implementation.

draft-ietf-behave-nat-mib-11 triggers notifications based on the ratio of a= ctive address and port mappings using a given pool to the total number of a= ddress-port combinations made available by the pool, expressed as a percent= age. As David Harrington pointed out, this makes a lot of demands on the ag= ent processor. We have some alternatives:

1) No notification: leave any processing to the management application.
=

The problem with this is that the ma= nagement application would effectively have to bulk fetch the full mapping = table to be able to compute pool usage. That could be much more taxing on t= he agent than computing pool usage by itself.

2) Trigger the high usage notification based on the rate of occurrence of o= ut-of-port events, with the same threshold value for all pools. This is rea= sonably valid statistically for a low threshold (i.e., taking the view that= any port exhaustion at all is actionable), but not terribly reliable in th= e 'paired' case, in that a single subscriber can dominate the resul= ts.

3) Trigger the high usage notification based on the rate of occurrence of o= ut-of-port events, with a higher threshold value based on pool size (addres= ses x ports) and sharing ratio. This requires some mathematical analysis an= d per-pool configuration.

I think= these two options are non-starters because they rely on heuristics rather = than hard metrics. Plus, maintaining a "rate of occurence" is not= much less involved than computing pool usage in the first place.

Suggestion: We need to see what current NATs report, especi= ally CGNs. For many vendors the documentation is public...

Simon
--001a1132f75ee70aa40506679a39-- From nobody Mon Oct 27 18:23:10 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4294F1A882C; Mon, 27 Oct 2014 18:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 fBYgggGVUwhF; Mon, 27 Oct 2014 18:23:01 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37E61A8829; Mon, 27 Oct 2014 18:23:00 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id hn18so7014582igb.5 for ; Mon, 27 Oct 2014 18:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KvFfxG+4wKTNQ/6vUSPu/ZM2wzh4dxzVf/Ns+egny5Q=; b=uhqfesqe9LCnBmFGzdiwz3lbYVhNM4iLGvPwEWqvlU6yvZ3NgPgxeU5RZ+oSMqY8fD mGDQn0LrDkkx7gBPmiM4EvOY/ZSIcrwwr2PQS7kHG1G/P4P0xy8FKOZ+RD3m9ikJY8hw aehwi/v+RvKV5nPWijhSVnD9EL1l9qo/c4j1zcqc1xda2CRew9N1nyaYrAHH1CqpUSpK OTWKju40gTvELYTyY+LrYKvlrg78L6tXssS/9wvySIyjXtIz/4vTcevmolUnvTmU+TKd wlVJrmcx6zA8p+tsD3bi+sGKU91e/AASVcCVw6jlRs5Wq+8n0OXBSB9PNWqfSj9gnTdr +uoA== X-Received: by 10.107.172.210 with SMTP id v201mr123690ioe.19.1414459380167; Mon, 27 Oct 2014 18:23:00 -0700 (PDT) Received: from [192.168.0.102] (dsl-207-112-123-240.tor.primus.ca. [207.112.123.240]) by mx.google.com with ESMTPSA id a10sm241278igo.22.2014.10.27.18.22.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 18:22:59 -0700 (PDT) Message-ID: <544EEFEA.5040801@gmail.com> Date: Mon, 27 Oct 2014 21:22:50 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <544D772F.6060009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/7W9O5KsrMhMjUkMYDPGH7Y602I4 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: [BEHAVE] Out of port errors, resource errors in NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 01:23:03 -0000 Leaving aside the notification question for research, the discussion below suggests that the boundary between port exhaustion and address exhaustion is somewhat indeterminate. The MIB currently has two counters (showing up in various tables, another issue), OutOfPortErrors and ResourceErrors, with the latter supposedly picking up address exhaustion. I'd suggest we make the first one OutOfAddressPortErrors and thereby eliminate the ambiguity. I'd also call these Drops rather than Errors to make the consequences clearer. Tom Taylor On 27/10/2014 9:35 AM, Simon Perreault wrote: > On Sun, Oct 26, 2014 at 6:35 PM, Tom Taylor > wrote: ... > > The problem with NAT pool monitoring is that the pool actually contains two >> resources, addresses and ports, and how they get used up depends on RFC >> 4787 pooling behaviour. >> > > Well, yes, but I don't see how this is a problem. > > Keep in mind that some NATs don't bother with ports and allocate full > addresses. That is supported with the current pool and mapping models. > > For the RECOMMENDED pooling behaviour of 'paired', port exhaustion occurs >> when all the ports for the desired protocol available to the subscriber on >> a mapped external address are used up, the NAT cannot (for reasons of >> policy or availability) assign additional ports to that subscriber on that >> same address, and the NAT cannot assign an additional address containing >> free ports to that subscriber. (This last condition is subject to >> discussion: is it port exhaustion or address exhaustion?) >> > > It depends on what you mean by "cannot". A "paired" NAT may decide to > allocate a mapping from any other available address and not even consider > this an exhaustion condition. It may decide to replace the current address > mapping with this new address. Or it may consider this a "temporary address > mapping" to be reverted eventually. Or it may not record this new mapping > at all, and just allocate mappings from any random address as long as the > primary address is exhausted. Or it may refuse to create a new mapping, as > you seem to imply. > > We should not "think" too much about NAT implementation... What matters is > observable behaviour, and in particular observable behaviour that is > general enough that it can be usefully modelled in a MIB. Whatever triggers > an exhaustion event is not absolutely important. We just need to be able to > report it. It will be up to the NAT administrator to determine, based on > the particular NAT implementation, what exactly exhaustion means. Some NATs > are very configurable in this matter. > > For a pooling behaviour of 'arbitrary', port exhaustion occurs when there >> is no available port for the desired protocol at any of the addresses in >> the pool. Clearly port exhaustion will be a rarer event in the 'arbitrary' >> case. >> > ... From nobody Tue Oct 28 06:58:04 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D6A1A8831 for ; Tue, 28 Oct 2014 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6S0v6mwujGTN for ; Tue, 28 Oct 2014 06:58:02 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5651A0404 for ; Tue, 28 Oct 2014 06:58:01 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id l4so647189lbv.4 for ; Tue, 28 Oct 2014 06:58:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FjzvvTVGM1iAosnzo4a9h1WsxqYb48bAEnkhPv65l60=; b=PdllH2+w7lY7iVFMbE1i376QQ6Ql4BOQz7ijxqcHg7IEhOpu+lKhszh0zMeuNIbwx5 T6G08/9ojz/eB287omzF4zCRWVFaoNNwW2Thj3LcOV1psFq0NQUAKflx4q/GfO6PhPUK prYZMj9/5VQ+5gRBx/ad2luarz7FzcVzyqWXZouDKKVc7rFEQedJJUGTfBPq5mQvHHU9 PWp6vBLp5SZ9/kb9ju/A77LKY74Nt2nc01RrViNXoEAyhOf9Q0vZmyvjQEl+JIS/Ni94 0zjJmeoWZZLKnIXU/D9Kp2KB/dy4mZrAeinftuGJ55IL5gZmHNHhEIowIioBKD4HnpUL Y5gQ== X-Gm-Message-State: ALoCoQkgJv2R7xzAD09/dGoTIrBXLXYiZsXyg5XEx5UoblDzNlQ4mFTKEqgjA8mglq316GTnz6Ae MIME-Version: 1.0 X-Received: by 10.153.7.107 with SMTP id db11mr4247691lad.35.1414504679910; Tue, 28 Oct 2014 06:57:59 -0700 (PDT) Received: by 10.25.167.20 with HTTP; Tue, 28 Oct 2014 06:57:59 -0700 (PDT) In-Reply-To: <544EEFEA.5040801@gmail.com> References: <544D772F.6060009@gmail.com> <544EEFEA.5040801@gmail.com> Date: Tue, 28 Oct 2014 09:57:59 -0400 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a113456a0fac62205067c089f Archived-At: http://mailarchive.ietf.org/arch/msg/behave/QJrKmbvxHvjjHm1vONCrtbZK3h4 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] Out of port errors, resource errors in NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 13:58:03 -0000 --001a113456a0fac62205067c089f Content-Type: text/plain; charset=UTF-8 On Mon, Oct 27, 2014 at 9:22 PM, Tom Taylor wrote: > Leaving aside the notification question for research, the discussion below > suggests that the boundary between port exhaustion and address exhaustion > is somewhat indeterminate. The MIB currently has two counters (showing up > in various tables, another issue), OutOfPortErrors and ResourceErrors, with > the latter supposedly picking up address exhaustion. I'd suggest we make > the first one OutOfAddressPortErrors and thereby eliminate the ambiguity. > I'd also call these Drops rather than Errors to make the consequences > clearer. Works for me! Thanks, Simon --001a113456a0fac62205067c089f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Oct 27, 2014 at 9:22 PM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
Leaving asid= e the notification question for research, the discussion below suggests tha= t the boundary between port exhaustion and address exhaustion is somewhat i= ndeterminate. The MIB currently has two counters (showing up in various tab= les, another issue), OutOfPortErrors and ResourceErrors, with the latter su= pposedly picking up address exhaustion. I'd suggest we make the first o= ne OutOfAddressPortErrors and thereby eliminate the ambiguity. I'd also= call these Drops rather than Errors to make the consequences clearer.

Works for me!

<= div class=3D"gmail_extra">Thanks,
Simon
--001a113456a0fac62205067c089f-- From nobody Tue Oct 28 09:01:03 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356731A8AEA; Tue, 28 Oct 2014 09:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SnHFa7MkN9pa; Tue, 28 Oct 2014 09:00:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 201891A8F3D; Tue, 28 Oct 2014 09:00:40 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6AFCA40396; Tue, 28 Oct 2014 12:00:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: JF Tremblay In-Reply-To: <544EEFEA.5040801@gmail.com> Date: Tue, 28 Oct 2014 12:00:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544D772F.6060009@gmail.com> <544EEFEA.5040801@gmail.com> To: "behave@ietf.org" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/behave/Q16eFVWXuYSsgPOT0YQIP4lq-TY Cc: "opsawg@ietf.org" Subject: Re: [BEHAVE] Out of port errors, resource errors in NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:00:57 -0000 > On Oct 27, 2014, at 9:22 PM, Tom Taylor = wrote: >=20 > Leaving aside the notification question for research, the discussion = below suggests that the boundary between port exhaustion and address = exhaustion is somewhat indeterminate. The MIB currently has two counters = (showing up in various tables, another issue), OutOfPortErrors and = ResourceErrors, with the latter supposedly picking up address = exhaustion. I'd suggest we make the first one OutOfAddressPortErrors and = thereby eliminate the ambiguity. I'd also call these Drops rather than = Errors to make the consequences clearer. +1=20 I believe it=E2=80=99s useful for a NAT operator to differentiate = between these types of errors.=20 As Tom mentioned, we shouldn=E2=80=99t dwelve* in = implementation-specific details, but the MIB should provide enough = flexibility to express real-life error conditions in a meaningful way. = Where meaningful =3D=3D clear enough for an operation person not to have = to dig the MIB definition at 2:00 in the morning to figure out which = problem needs fixing.=20 This begs the question: are these objects sufficient and aptly named in = the MIB to reach the goal above?=20 Let=E2=80=99s take a few examples of real-life CGN error cases (they are = fairly common in my experience, but your-experience-may-vary-of-course):=20= 1. Out-of-ports because an administrative limit of port-per-user is = reached.=20 2. Out-of-ports because a single address doesn=E2=80=99t have enough = available ports and address =E2=80=9Cpairing=E2=80=9D is enforced.=20 3. Out-of-ports/addresses because all addresses in all configured pools = do not have enough available ports.=20 4. Out-of-addresses because an administrative limit of users per address = is reached on all addresses of all configured pools. =20 (in the above, =E2=80=9Cuser=E2=80=9D is loosely used as meaning a = single inside source address) MIB behaviour (in my opinion):=20 1. natQuotaDrops incremented 2. Is natQuotaDrops or natOutOfPortErrors incremented? The MIB prohibits = incrementing both. natOutOfPortsError would probably be preferable.=20 3. natOutOfAddressPortErrors incremented 4. natQuotaDrops incremented (probably) Note that natResourceErrors isn=E2=80=99t used above, but it=E2=80=99s = probably useful to keep it as it is now.=20 Possible corrective actions:=20 a) Add addresses to currently configured pools: cases 3 and 4 b) Review the administrative boundaries policies (long term action): = cases 2 and 4 In this light, Tom=E2=80=99s suggestion of adding = natOutOfAddressesPortErrors is definitely useful, as it covers case 3 = well and provides a way to differentiate it from case 1. However the = current fields might not be sufficient to cover all cases, like = differentiating cases 1 and 4 above. This might be left to = implementation-dependant enterprise MIBs, but it would have been nice to = have enough coverage in the standard MIB for most common cases.=20 Suggestion:=20 natQuotaDrops could be split in natAddressQuotaDrops and = natPortsQuotaDrops. It would make it somewhat clearer that a "per = port=E2=80=9D or a =E2=80=9Cper address=E2=80=9D policy is involved.=20 My 2.302 cents (the exchange rate isn=E2=80=99t what it used to be)=20 /JF * I just learned that =E2=80=9Cdwelve=E2=80=9D isn=E2=80=99t a real word = after all. Interesting, I=E2=80=99ll go to sleep a little less idiot = tonight (loose translation of a local expression).=20 =20= From nobody Tue Oct 28 12:53:28 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0701ACDAF; Tue, 28 Oct 2014 12:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 LyuldtGWLH1C; Tue, 28 Oct 2014 12:53:23 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA361ACD6E; Tue, 28 Oct 2014 12:53:05 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id at20so1457261iec.6 for ; Tue, 28 Oct 2014 12:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=56WtRhAiU9QGVu1zXBStHqllyFbZ/GWST21BR1iPWFM=; b=wEHGEglyCA0erVKagljtz3YqHaMTj4OsVFzFLaj//X8120FIjcKTaAA8Xj9tUJ/Gbf pbWB7EpGCZbXdSm425pACgx1/vElGN/3cp2r+HLua+9skCuUJYIU16yvqUM3rUNkvu3f 6UfNe8oIEv7/4mTw3ickNthupFjKw7h5bw8MkBUavZRd2yZ8OR2/dkwcpPdxr8c3Jb2b eDnOsHsHG8Wg65Wzoz0Iwx1GzGjNaPRwrIbnKBRNB0275clg+AbI+r1dYDGZDO4iYS9p 18IrDAp8bvu4zhFwWcc5c5umGtjvtwdmg0B4SHwaiGfRhx1yemaY6uidVzwOSUuaJfA5 ewDw== X-Received: by 10.107.15.8 with SMTP id x8mr6491549ioi.13.1414525985011; Tue, 28 Oct 2014 12:53:05 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-78-153.tor.primus.ca. [173.206.78.153]) by mx.google.com with ESMTPSA id a192sm1057651ioa.34.2014.10.28.12.53.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 12:53:04 -0700 (PDT) Message-ID: <544FF421.60801@gmail.com> Date: Tue, 28 Oct 2014 15:53:05 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: JF Tremblay , "behave@ietf.org" References: <544D772F.6060009@gmail.com> <544EEFEA.5040801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/GWFzlrQtKra7woD5RoOaUa7pIOA Cc: "opsawg@ietf.org" Subject: Re: [BEHAVE] [OPSAWG] Out of port errors, resource errors in NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:53:25 -0000 At the end with [PTT]. On 28/10/2014 12:00 PM, JF Tremblay wrote: > >> On Oct 27, 2014, at 9:22 PM, Tom Taylor wrote: >> >> Leaving aside the notification question for research, the discussion below suggests that the boundary between port exhaustion and address exhaustion is somewhat indeterminate. The MIB currently has two counters (showing up in various tables, another issue), OutOfPortErrors and ResourceErrors, with the latter supposedly picking up address exhaustion. I'd suggest we make the first one OutOfAddressPortErrors and thereby eliminate the ambiguity. I'd also call these Drops rather than Errors to make the consequences clearer. > > +1 > I believe it’s useful for a NAT operator to differentiate between these types of errors. > > As Tom mentioned, we shouldn’t dwelve* in implementation-specific details, but the MIB should provide enough flexibility to express real-life error conditions in a meaningful way. Where meaningful == clear enough for an operation person not to have to dig the MIB definition at 2:00 in the morning to figure out which problem needs fixing. > > This begs the question: are these objects sufficient and aptly named in the MIB to reach the goal above? > > Let’s take a few examples of real-life CGN error cases (they are fairly common in my experience, but your-experience-may-vary-of-course): > 1. Out-of-ports because an administrative limit of port-per-user is reached. > 2. Out-of-ports because a single address doesn’t have enough available ports and address “pairing” is enforced. > 3. Out-of-ports/addresses because all addresses in all configured pools do not have enough available ports. > 4. Out-of-addresses because an administrative limit of users per address is reached on all addresses of all configured pools. > (in the above, “user” is loosely used as meaning a single inside source address) > > MIB behaviour (in my opinion): > 1. natQuotaDrops incremented > 2. Is natQuotaDrops or natOutOfPortErrors incremented? The MIB prohibits incrementing both. natOutOfPortsError would probably be preferable. > 3. natOutOfAddressPortErrors incremented > 4. natQuotaDrops incremented (probably) > > Note that natResourceErrors isn’t used above, but it’s probably useful to keep it as it is now. > > Possible corrective actions: > a) Add addresses to currently configured pools: cases 3 and 4 > b) Review the administrative boundaries policies (long term action): cases 2 and 4 > > In this light, Tom’s suggestion of adding natOutOfAddressesPortErrors is definitely useful, as it covers case 3 well and provides a way to differentiate it from case 1. However the current fields might not be sufficient to cover all cases, like differentiating cases 1 and 4 above. This might be left to implementation-dependant enterprise MIBs, but it would have been nice to have enough coverage in the standard MIB for most common cases. > > Suggestion: > natQuotaDrops could be split in natAddressQuotaDrops and natPortsQuotaDrops. It would make it somewhat clearer that a "per port” or a “per address” policy is involved. > > My 2.302 cents (the exchange rate isn’t what it used to be) > > /JF > [PTT] Looks to me like the solution might be to have a counter per administrative limit, plus one each for can't allocate an address mapping, can't allocate an address-port mapping. Then a general "other resources" counter. That's not distinguishing your cases 2 and 3, but based on what Simon was saying this seems less tied to implementation than trying to make that distinction. Case 3 should make itself evident in other ways (resource pool utilization). > > * I just learned that “dwelve” isn’t a real word after all. Interesting, I’ll go to sleep a little less idiot tonight (loose translation of a local expression). > [PTT] You've mingled two applicable words. You could have said "dwell on implementation details" or "delve into implementation details". > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Tue Oct 28 13:34:44 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D4A1ACE15; Tue, 28 Oct 2014 13:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TRACKER_ID=1.306, T_RP_MATCHES_RCVD=-0.01] autolearn=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 A1RVd2ZYrSuL; Tue, 28 Oct 2014 13:34:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0F1ACDEC; Tue, 28 Oct 2014 13:34:38 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D9A16400A5; Tue, 28 Oct 2014 16:34:37 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_13E9AC79-E623-4BC1-B3F9-81E672023DFC" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: JF Tremblay In-Reply-To: <544FF421.60801@gmail.com> Date: Tue, 28 Oct 2014 16:34:37 -0400 Message-Id: References: <544D772F.6060009@gmail.com> <544EEFEA.5040801@gmail.com> <544FF421.60801@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/behave/inLYsmBpfhOH9cyjh79H32Zwzbk Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [OPSAWG] Out of port errors, resource errors in NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:34:40 -0000 --Apple-Mail=_13E9AC79-E623-4BC1-B3F9-81E672023DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 28, 2014, at 3:53 PM, Tom Taylor = wrote: > At the end with [PTT]. >=20 > On 28/10/2014 12:00 PM, JF Tremblay wrote: >>=20 >>=20 >> Let=E2=80=99s take a few examples of real-life CGN error cases (they = are fairly common in my experience, but = your-experience-may-vary-of-course): >> 1. Out-of-ports because an administrative limit of port-per-user is = reached. >> 2. Out-of-ports because a single address doesn=E2=80=99t have enough = available ports and address =E2=80=9Cpairing=E2=80=9D is enforced. >> 3. Out-of-ports/addresses because all addresses in all configured = pools do not have enough available ports. >> 4. Out-of-addresses because an administrative limit of users per = address is reached on all addresses of all configured pools. >> (in the above, =E2=80=9Cuser=E2=80=9D is loosely used as meaning a = single inside source address) >>=20 >> MIB behaviour (in my opinion): >> 1. natQuotaDrops incremented >> 2. Is natQuotaDrops or natOutOfPortErrors incremented? The MIB = prohibits incrementing both. natOutOfPortsError would probably be = preferable. >> 3. natOutOfAddressPortErrors incremented >> 4. natQuotaDrops incremented (probably) >>=20 >> Suggestion: >> natQuotaDrops could be split in natAddressQuotaDrops and = natPortsQuotaDrops. It would make it somewhat clearer that a "per = port=E2=80=9D or a =E2=80=9Cper address=E2=80=9D policy is involved. >>=20 > [PTT] Looks to me like the solution might be to have a counter per = administrative limit, plus one each for can't allocate an address = mapping, can't allocate an address-port mapping. Is that 4 counters? {admin | !admin} x { addresses | addresses-ports } For example:=20 natAdminOutOfAddressesDrops natAdminOutOfAddressesPortsDrops natOutOfPortsDrops natOutOfAddressesPortsDrops Not sure natAdminOutOfAddressesPortsDrops above makes any sense. An = administrative policy will be on ports only. No implementation will = specify a limit in address-ports (even if this is what it is, actually).=20= Suggestion:=20 natAdminOutOfAddressesDrops natAdminOutOfPortsDrops natOutOfPortsDrops natOutOfAddressesPortsDrops natResourceErrors Then the MIB behavior according to the scenarios above become:=20 1. natAdminOutOfPortsDrops++ 2. natOutOfPortsDrops++ 3. natOutOfAddressesPortsDrops++ 4. natAdminOutOfAddressesDrops++ Makes sense? > Then a general "other resources" counter. Ok. (added above) > That's not distinguishing your cases 2 and 3, but based on what Simon = was saying this seems less tied to implementation than trying to make = that distinction. Case 3 should make itself evident in other ways = (resource pool utilization). Agreed, =E2=80=9Cutilization=E2=80=9D information would provide an = indication of a problem, but it will not provide an indication of how = severe the problem is or has been. By looking at a counter, an operator = can get additional information (how many drops actually happened).=20 JF --Apple-Mail=_13E9AC79-E623-4BC1-B3F9-81E672023DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 28, 2014, at 3:53 PM, Tom Taylor <tom.taylor.stds@gmail.com> wrote:
At the end with = [PTT].

On 28/10/2014 12:00 PM, JF = Tremblay wrote:

Let=E2=80=99s = take a few examples of real-life CGN error cases (they are fairly common = in my experience, but your-experience-may-vary-of-course):
1. Out-of-ports because an administrative limit of = port-per-user is reached.
2. Out-of-ports because a single = address doesn=E2=80=99t have enough available ports and address = =E2=80=9Cpairing=E2=80=9D is enforced.
3. = Out-of-ports/addresses because all addresses in all configured pools do = not have enough available ports.
4. Out-of-addresses = because an administrative limit of users per address is reached on all = addresses of all configured pools.
(in the above, = =E2=80=9Cuser=E2=80=9D is loosely used as meaning a single inside source = address)

MIB behaviour (in my opinion):
1. natQuotaDrops incremented
2. Is = natQuotaDrops or natOutOfPortErrors incremented? The MIB prohibits = incrementing both. natOutOfPortsError would probably be preferable.
3. natOutOfAddressPortErrors incremented
4. = natQuotaDrops incremented = (probably)

Suggestion:
natQuotaDrops could be split in natAddressQuotaDrops and = natPortsQuotaDrops. It would make it somewhat clearer that a "per = port=E2=80=9D or a =E2=80=9Cper address=E2=80=9D policy is involved.

[PTT] Looks to me like the solution might be to = have a counter per administrative limit, plus one each for can't = allocate an address mapping, can't allocate an address-port = mapping.

Is that = 4 counters? {admin | !admin} x { addresses | addresses-ports = }

For = example: 
natAdminOutOfAddressesDrops
natAdminOut= OfAddressesPortsDrops
natOutOfPortsDrops
natOutOfAddre= ssesPortsDrops

Not sure = natAdminOutOfAddressesPortsDrops above makes any sense. An = administrative policy will be on ports only. No implementation will = specify a limit in address-ports (even if this is what it is, = actually). 

Suggestion: 
natAdminOutOfAddres= sesDrops
natAdminOutOfPortsDrops
natOutOfPortsDrops
natOutOfAddressesPortsDrops
natResourceErrors

Then the MIB behavior according to the = scenarios above become: 

1. = natAdminOutOfPortsDrops++
2. natOutOfPortsDrops++
3. natOutOfAddressesPortsDrops++
4. = natAdminOutOfAddressesDrops++

Makes = sense?

Then a general "other = resources" counter.

Ok. (added above)

That's not distinguishing your cases 2 and 3, = but based on what Simon was saying this seems less tied to = implementation than trying to make that distinction. Case 3 should make = itself evident in other ways (resource pool utilization).

Agreed, =E2=80=9Cutilization=E2=80=9D information would = provide an indication of a problem, but it will not provide an = indication of how severe the problem is or has been. By looking at a = counter, an operator can get additional information (how many drops = actually happened). 

JF


= --Apple-Mail=_13E9AC79-E623-4BC1-B3F9-81E672023DFC-- From nobody Tue Oct 28 13:47:51 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66B01A8AEC; Tue, 28 Oct 2014 13:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 rNTA1B8JiDnJ; Tue, 28 Oct 2014 13:47:44 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D391A8AE7; Tue, 28 Oct 2014 13:47:44 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so1617709ier.30 for ; Tue, 28 Oct 2014 13:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Lw2LDByxG6C39dIboJ+tBZJUmaFO3kO1w9JG8n6jzKA=; b=F1iH736UJ+mqRTjRfQKeD1rRZFkKZSGprGC2bnSS+VemTJktzls07A7bqV5s3YwH+4 UEj95ao0rvMHd5sYTqNAB6iTnyrgWhejJfLZrnGDHsHxcW9C+rRi4JfuUG71LV6aEbFl 6otWI99M0CS2siK3MFyZe5rAV99hEH2zJO4iMq+QmbUMPf870dpEYIORXICKcK0pJRw+ V4filOU58lx6drD2YKZNy4VgiKOpTr9STIze/ktwD3/HHmK28U3XUYia27REq4AybmAy ArvaBN0Eki4odl4UN17+tViSeyf/UDLCEcR7oR3e18TKZj0uICKhTZBJYHIoyfu97v7C 5NqQ== X-Received: by 10.42.24.10 with SMTP id u10mr6362783icb.58.1414529263688; Tue, 28 Oct 2014 13:47:43 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-78-153.tor.primus.ca. [173.206.78.153]) by mx.google.com with ESMTPSA id 40sm1118126iom.43.2014.10.28.13.47.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 13:47:43 -0700 (PDT) Message-ID: <545000E7.50901@gmail.com> Date: Tue, 28 Oct 2014 16:47:35 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: JF Tremblay References: <544D772F.6060009@gmail.com> <544EEFEA.5040801@gmail.com> <544FF421.60801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/NPjp4A3nCbMRGw7TG6h3l86E640 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [OPSAWG] Out of port errors, resource errors in NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:47:48 -0000 Response with [PTT2]. On 28/10/2014 4:34 PM, JF Tremblay wrote: > >> On Oct 28, 2014, at 3:53 PM, Tom Taylor wrote: >> At the end with [PTT]. >> >> On 28/10/2014 12:00 PM, JF Tremblay wrote: >>> >>> >>> Let’s take a few examples of real-life CGN error cases (they are fairly common in my experience, but your-experience-may-vary-of-course): >>> 1. Out-of-ports because an administrative limit of port-per-user is reached. >>> 2. Out-of-ports because a single address doesn’t have enough available ports and address “pairing” is enforced. >>> 3. Out-of-ports/addresses because all addresses in all configured pools do not have enough available ports. >>> 4. Out-of-addresses because an administrative limit of users per address is reached on all addresses of all configured pools. >>> (in the above, “user” is loosely used as meaning a single inside source address) >>> ...>>> >> [PTT] Looks to me like the solution might be to have a counter per administrative limit, plus one each for can't allocate an address mapping, can't allocate an address-port mapping. > > Is that 4 counters? {admin | !admin} x { addresses | addresses-ports } > > For example: > natAdminOutOfAddressesDrops > natAdminOutOfAddressesPortsDrops > natOutOfPortsDrops > natOutOfAddressesPortsDrops > > Not sure natAdminOutOfAddressesPortsDrops above makes any sense. An administrative policy will be on ports only. No implementation will specify a limit in address-ports (even if this is what it is, actually). > > Suggestion: > natAdminOutOfAddressesDrops > natAdminOutOfPortsDrops > natOutOfPortsDrops > natOutOfAddressesPortsDrops > natResourceErrors > > Then the MIB behavior according to the scenarios above become: > > 1. natAdminOutOfPortsDrops++ > 2. natOutOfPortsDrops++ > 3. natOutOfAddressesPortsDrops++ > 4. natAdminOutOfAddressesDrops++ > > Makes sense? > [PTT2] It works. If we keep to the MIB in its current form, we need two more administrative counters because we have two more limits: on fragments, and on number of subscribers with active mappings. >> Then a general "other resources" counter. > > Ok. (added above) > >> That's not distinguishing your cases 2 and 3, but based on what Simon was saying this seems less tied to implementation than trying to make that distinction. Case 3 should make itself evident in other ways (resource pool utilization). > > Agreed, “utilization” information would provide an indication of a problem, but it will not provide an indication of how severe the problem is or has been. By looking at a counter, an operator can get additional information (how many drops actually happened). > > JF > > > From nobody Tue Oct 28 15:24:57 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EC41A0073 for ; Tue, 28 Oct 2014 15:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 rcdzBgTcYYmZ for ; Tue, 28 Oct 2014 15:24:49 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925BB1A000C for ; Tue, 28 Oct 2014 15:24:34 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rd18so1774204iec.21 for ; Tue, 28 Oct 2014 15:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=YkdWJjlj5YWP2Ld7BCNiJSEEjG7Z9RoDGwk7uZOu9SM=; b=r7zirSs0vARGkrDz3RMkeV+hGoi3Rf80iShYS0OWS5EL4dLO9ErrsVwJ9P+1yLe0Qq 7goGRt0MSuisb4IYK7YMJH58uIiFbsmyaVxpfrGKVnSxWH665Iun0LE4Jy5Sx3OQMoB5 NcNnA1ZvmaC2SBANLFqUTH+gjStKXBshnNQVe2WXMbeFx+mhkfhQumhryIU+RRLI8NPj 9lP5Xt/ljXhKB+el1SSmUxWedB7WIjcqPyettR6DmoVAuQ9pG/fqCk1b68Ba8BGkdxg1 IlJfFhWr9FT5+Y+GqaTRPr1/4joKn65+DWFVXB7rZ+PYT9qFv/BXawY/PbtfCYn8dC9Y 7fDg== X-Received: by 10.43.165.66 with SMTP id mv2mr6659247icc.51.1414535073899; Tue, 28 Oct 2014 15:24:33 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-78-153.tor.primus.ca. [173.206.78.153]) by mx.google.com with ESMTPSA id hi1sm1493512igb.18.2014.10.28.15.24.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 15:24:33 -0700 (PDT) Message-ID: <5450179C.7080303@gmail.com> Date: Tue, 28 Oct 2014 18:24:28 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/GGGSBdHzbjiN7Jpvq1vvbog_Kkk Subject: [BEHAVE] MIB Issue 006: Separate document for deprecation of NAT MIB v1 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:24:53 -0000 I have closed MIB Issue 006: Separate document for deprecation of NAT MIB v1, http://trac.tools.ietf.org/wg/behave/trac/wiki/MibIss006 based on the submission of draft-perrault-behave-deprecate-nat-mib-v1. Tom Taylor From nobody Wed Oct 29 08:06:44 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5984E1A6EF1; Tue, 28 Oct 2014 20:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 SLEDiOozqGJt; Tue, 28 Oct 2014 20:09:02 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id AC3B51A032D; Tue, 28 Oct 2014 20:09:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=K6w5Lollo21LK1kAt+UsTYB8AQi5md07z79VMAWA3jYy1GrlRRjwGXLdSqK52InM; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XjJd1-0002p3-Nn; Tue, 28 Oct 2014 22:08:55 -0500 Received: from 76.254.52.158 by webmail.earthlink.net with HTTP; Tue, 28 Oct 2014 23:08:55 -0400 Message-ID: <28462556.1414552135464.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Tue, 28 Oct 2014 20:08:55 -0700 (GMT-07:00) From: Randy Presuhn To: Simon Perreault , Tom Taylor Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f2e9d738bb29384a449184858e5bc5ae1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/MCsyAyENIsGXyE3e1EiQrRAfHGU X-Mailman-Approved-At: Wed, 29 Oct 2014 08:06:33 -0700 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 03:09:08 -0000 Hi - >From: Simon Perreault >Sent: Oct 27, 2014 6:35 AM >To: Tom Taylor >Cc: "opsawg@ietf.org" , "behave@ietf.org" >Subject: Re: [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent ... >> draft-ietf-behave-nat-mib-11 triggers notifications based on the ratio of >> active address and port mappings using a given pool to the total number of >> address-port combinations made available by the pool, expressed as a >> percentage. As David Harrington pointed out, this makes a lot of demands on >> the agent processor. We have some alternatives: ... I haven't seen David's original comment, but I don't see how implementation to match the behaviour described here is at all demanding computationally. In a case like this, there are two pieces of information that change infrequently: the threshold and the total number of combinations made available by the pool; and one piece which changes frequently: the number of active mappings using the pool. A typical agent implementation strategy strategy for something like this simply (re-)computes the *integer* threshold against which the rapidly changing piece of information is to be compared. All the "expensive" processing (typically just a couple of divisions and multiplies) in terms of "ratios" only happens when processing a *configuration* change. The frequent operation (threshold check) is a simple integer compare in the same units as the variable of interest. Randy From nobody Wed Oct 29 08:40:11 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9151A0673; Wed, 29 Oct 2014 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 9XF_yxANrKgH; Wed, 29 Oct 2014 08:40:07 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE631A049A; Wed, 29 Oct 2014 08:39:21 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id a13so3341624igq.11 for ; Wed, 29 Oct 2014 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e7GN3cYld9PKSww10VDQsfgeKcCFVZWGjsf9W3+O1Qs=; b=kij1R/DeZgu0lo+yjs1eYsMm8zc2Xa/xVJ12dbA1lMU3oaP98pF27AxKRTWWuojngU mrRb5iA8YpKJhTjQVrOR/IuSoK+Pn0oLIY4ZcneX1b7Tr8bnNRkpvn0iCCkZ1WuOVr2b NdzTZ9uXGfaZsc5GrlCVIkti3oPpke5+FWAjwNNOYkgZkcZmOI0vSQEUAqmStgf5PGIy 3zGkYye1ZE95JyXfT257zD2AH+MhPkCdJoc/R1GFskLABjlm2ImyLpSb+NnsaWYteX2O WMwEPoSZCN+0t4T2UlR5Pue/Y/NVXASR8YylvGxC8NlBsVATiWYpPAv+0Tf/0xspvxC5 ocWw== X-Received: by 10.50.110.65 with SMTP id hy1mr39249963igb.13.1414597161123; Wed, 29 Oct 2014 08:39:21 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-91-10.tor.primus.ca. [173.206.91.10]) by mx.google.com with ESMTPSA id f8sm2309411iof.15.2014.10.29.08.39.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 08:39:20 -0700 (PDT) Message-ID: <54510A29.4050204@gmail.com> Date: Wed, 29 Oct 2014 11:39:21 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Randy Presuhn , Simon Perreault References: <28462556.1414552135464.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> In-Reply-To: <28462556.1414552135464.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/60_dqvsMJI0Y8c5bq4_oeQs20fM Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:40:09 -0000 Good point, thanks. Tom Taylor On 28/10/2014 11:08 PM, Randy Presuhn wrote: > Hi - > >> From: Simon Perreault >> Sent: Oct 27, 2014 6:35 AM >> To: Tom Taylor >> Cc: "opsawg@ietf.org" , "behave@ietf.org" >> Subject: Re: [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent > ... >>> draft-ietf-behave-nat-mib-11 triggers notifications based on the ratio of >>> active address and port mappings using a given pool to the total number of >>> address-port combinations made available by the pool, expressed as a >>> percentage. As David Harrington pointed out, this makes a lot of demands on >>> the agent processor. We have some alternatives: > ... > > I haven't seen David's original comment, but I don't see how > implementation to match the behaviour described here is > at all demanding computationally. > > In a case like this, there are two pieces of information that > change infrequently: the threshold and the total number of > combinations made available by the pool; and one piece which > changes frequently: the number of active mappings using the pool. > A typical agent implementation strategy strategy for something like > this simply (re-)computes the *integer* threshold against which > the rapidly changing piece of information is to be compared. > All the "expensive" processing (typically just a couple of divisions > and multiplies) in terms of "ratios" only happens when processing > a *configuration* change. The frequent operation (threshold check) > is a simple integer compare in the same units as the variable of > interest. > > Randy > From nobody Fri Oct 31 15:30:49 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB2B1A7030 for ; Fri, 31 Oct 2014 15:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 5TcNl80U8O9W for ; Fri, 31 Oct 2014 15:30:46 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298EE1A7029 for ; Fri, 31 Oct 2014 15:30:46 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id a13so1817748igq.5 for ; Fri, 31 Oct 2014 15:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Reh9R32/4h4bb8+f3RfqSxZcjKhGR80CO+ToLx1rGpQ=; b=faj3pgnNiMQCk+oMEMJM4a7A9lqtnBVaAK0IEl0j+O5UGp86+f5VfFQ04WEsgFTOuZ SUlBUsjYfGtpCaXVqnIPh0o4MZ9Tw4EmGOaKAkJmwI52o60LPUvpuCJE53IP4HNAhSUc PYFaKRqZtRnyaXb0PwzHln96m4VyJcin6ZTzsRNAO2ZQqddGa0vV9ujQnTqV7LbFBPs4 MIKGRwXKC+JpvEFx0h3ekVuaC58ZqcedztgtGEvIbSS0RHNanshhBA891gx5cMv9kvpI +VrJcOSWL6UaYknsyoerRTgSRE3BKOyj/EsyFSIbRd60cQ1u07uFSXuzKln2XnGgzVoV Clxw== X-Received: by 10.50.79.232 with SMTP id m8mr114188igx.11.1414794645648; Fri, 31 Oct 2014 15:30:45 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-96-237.tor.primus.ca. [173.206.96.237]) by mx.google.com with ESMTPSA id b184sm5837103ioe.3.2014.10.31.15.30.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 15:30:45 -0700 (PDT) Message-ID: <54540D96.20304@gmail.com> Date: Fri, 31 Oct 2014 18:30:46 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/HgFZcmiMRVg2nCMmaYpj-b5L9L4 Subject: [BEHAVE] MIB Issue 011 closed X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 22:30:48 -0000 MIB Issue 011, "Review whether two-level hierarchy needed for natPoolObjects, natPoolRangeTable needed", has been closed. You can see the resolution at http://trac.tools.ietf.org/wg/behave/trac/wiki/MibIss011 Tom Taylor