From nobody Fri Feb 6 13:43:01 2015 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 255D11A8880; Fri, 6 Feb 2015 13:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 gjyHppMlM5ZO; Fri, 6 Feb 2015 13:42:57 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E771A8876; Fri, 6 Feb 2015 13:42:00 -0800 (PST) Received: by iecat20 with SMTP id at20so4609332iec.3; Fri, 06 Feb 2015 13:41:59 -0800 (PST) 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=D0kOlwOdc/JtP7LVcSdyKa90I10Z9P12vYgVhu9cQtQ=; b=YKptMTJy0TghmLU6+xYUQ5YLBhcbrU4jd3ONWwTeBBUVM5tdKGnyUHEroxCnmRSOQd UEnwcsU0sxMw0qldRUIOsHydl1HhhWWVJDz1zqL7n3l6JPi/dqGHSA9tZDXNBnq5+pRG 58MiKNWhk57wxvK4hrYGXirE2wbsc2JLqu9zRtx0UlkY/ycTPJDXz9JO8loXrDheQaCa 8My1Ur22H9z9ltWpUSlUsjE6sAhO+o5JYCzfKAz0N82ZCUHY1YD/3MF0I/j0WQEFaNBl hJFt/jWu/gb2jr37UThrsSQPQrNdMbx52QunKY+8peQhMMyQAIa4Jxcn2rEMuI1lpiJ/ vRsA== X-Received: by 10.50.119.9 with SMTP id kq9mr4443463igb.36.1423258919426; Fri, 06 Feb 2015 13:41:59 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-73-98.tor.primus.ca. [173.206.73.98]) by mx.google.com with ESMTPSA id qs3sm1118326igb.8.2015.02.06.13.41.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 13:41:59 -0800 (PST) Message-ID: <54D5351B.3020601@gmail.com> Date: Fri, 06 Feb 2015 16:41:47 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Tina TSOU Subject: [BEHAVE] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics 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, 06 Feb 2015 21:42:59 -0000 draft-perrault-behave-natv2-mib-01 is almost ready. I considered in the past and rejected in my own mind a per-subscriber control on whether statistics are enabled or not for that subscriber. I rejected it thinking that the impact on processor consumption would be minimal, after the processor looked up the subscriber data in the first place. I've changed my mind for two reasons: first, that I probably made too many assumptions about implementation, and secondly, because the impact on storage requirements for per-subscriber statistics would be potentially huge if such a control were available. I therefore propose the following: 1) In the description of the CGN application scenario (Section 3.4 of draft-perrault-behave-natv2-mib-00), add the following sentence: "An implementation MAY limit the number of subscribers for which collection of statistics is enabled at any one time." 2) Add the following object to natv2SubscriberTable: natv2SubscriberCountersEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If true(1), accumulation of statistics in the counters for this subscriber is enabled and the current values of the counters can be presented to the manager. If false(1) (default), accumulation of statistics in the counters for this subscriber is disabled and the values presented to the manager MUST be zero regardless of their actual value. Whenever the value of this object changes, natv2SubscriberDiscontinuityTime MUST be updated to the time of change." ::= { natv2SubscriberEntry xx } Comments? Tom Taylor From nobody Sat Feb 7 06:25:03 2015 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 142C11A7018 for ; Sat, 7 Feb 2015 06:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zb-JLv-P1OO9 for ; Sat, 7 Feb 2015 06:24:59 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7761A6F3C for ; Sat, 7 Feb 2015 06:24:59 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-06v.sys.comcast.net with comcast id pSQS1p0022EPM3101SQyLq; Sat, 07 Feb 2015 14:24:58 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-ch2-07v.sys.comcast.net with comcast id pSQx1p00S2yZEBF01SQyLY; Sat, 07 Feb 2015 14:24:58 +0000 From: "ietfdbh" To: "'Tom Taylor'" , , References: <54D5351B.3020601@gmail.com> In-Reply-To: <54D5351B.3020601@gmail.com> Date: Sat, 7 Feb 2015 09:24:56 -0500 Message-ID: <011101d042e1$d90d80c0$8b288240$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHiE4rbppInpmPKEKd+xR7X7Tm7U5zBhlSA Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1423319098; bh=2XjQk0pUBQSEIgrQvmop+QflYz77c+SUf6Pz4DgJZ9E=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=PGwphbr4V+kPWkwPWn8AMT3MDZuPHbsety6hoaag0fkfxHMY32UmZS8b4mIqoXUpd pUsh+O+9G0Qe8v1tfXMCcZ6vYEWCq+ebhMu/HkIy6sp/vvTqoT9PRNBlj8WLN00uyk OgniXuSCR/2Bfb+JDHn6AyKYxA67YGFAhlmyPXFkbtcMwn2KCF7bPeSruRjfB83Ml7 MRkyZj3/YgpcxWc1kaFCEMubr7C0G8CVSSbxNtION5uIAeEp2q7In8t/WU0WSif3Dl Zr6S/lqnWXz9as7OESFklyET0BTNpculhFzolYCjnIDjmCOpBG9gD9mBUg/eVr2vuB AldWW3ho5qNsA== Archived-At: Cc: 'Tina TSOU' Subject: Re: [BEHAVE] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics 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, 07 Feb 2015 14:25:02 -0000 Hi, I think this is a bad idea. 1) I used to work at implementing a manager-side application for network management. I am concerned that dynamic enable/disable statistics gathering for this one MIB module could affect a lot of processing on the manager side. Managers already need to do a lot of work just to determine what MIB modules are supported by a device, and then to determine whether the device supports the MIB module in a compliant manner, or is missing some objects from the implementation, and whether the data reported is reliable. Adding a dynamic enable/disable collection at the subscriber level would seem to introduce a great deal of additional complexity for the manager, and more importantly, for the operator trying to diagnose a network problem. What impact would this on-off discontinuity have on the multiple manager scenario. What happens if one manager is monitoring a subscriber's stats for a period of time, and another manager goes in a mucks about with the continuity of collection? SNMP's design of counters - read, then read again and consider the delta, rather than zeroing counters constantly - is done to support the (very common) multiple manager scenario. The counters are consistently available, which is useful for historical trending, etc. The dynamic enable/disable of collection would seem to defeat that important SNMP design choice, and make interpretation of the discontinuous values over time more difficult and less useful. So I think there needs to be considerate discussion of the operational impact of such a switch in this MIB. 3) Do we have feedback from implementers discussing the actual or estimated implementation resources required to support subscriber stats, to justify needing such a switch? If device implementers think this really demands too many resources to support, maybe the subscriber stats should be removed from this MIB module and moved to a separate MIB module that is optional to implement, and then support of subscriber stats can be a question to be resolved between vendors and their customers. I would like to know that such a switch really is justified before adding such complexity. 4) SNMP SETs are not supported very widely, and with the approval and promotion of NETCONF as the IETF standard for configuration, I expect fewer operators will allow SETs even if supported by the agent implementation. Do we really need to standardize a read-write object to make it consistent across vendors, when many deployments may not support the SET capability? 5) All of which leads me to ask - Are the subscriber stats REALLY IMPORTANT to have? Here are some principles of MIB design to keep in mind (from RFC4188 and others): 1. Start with a small set of essential objects and add only as further objects are needed. 2. Require that objects be essential for either fault or configuration management. 3. Consider evidence of current use and/or utility. 4. Limit the total number of objects. 5. Exclude objects that are simply derivable from others in this or other MIB modules. 6. Avoid causing critical sections to be heavily instrumented. The guideline that was followed is one counter per critical section per layer. If per-subscriber stats can be enabled/disabled, does the NATv2 MIB meet these principles? Are these stats **essential** for fault management? If operators think they really are not essential enough to keep them enabled at all times, do we really NEED subscriber stats in the MIB module? If we do NEED them for fault management, what impact does turning them off have on fault management? Are non-standard per-subscriber stats currently being used for fault management? Do operators currently collect and utilize per-subscriber stats through the available non-standard interfaces of NAT devices? What do they do with these stats, so we can understand the design requirements to support these current use cases? Is standardizing these stats in the MIB really important to operators for apples-to-apples comparison across devices from multiple vendors? 6) Another principle about good agent implementation is "never mislead the operator". It was a common problem that early SNMP agent implementations reported zero values, when objects were actually not implemented. This was misleading to operators, causing delays in resolving faults, and wasting operators' time at critical moments. This proposed text certainly fails that principle: ". If false(1) > (default), accumulation of statistics in the counters for > this subscriber is disabled and the values presented to the > manager MUST be zero regardless of their actual value." If a counter is disabled, then it would be more appropriate to not report a value, and to return an error/exception instead. -- I would like to see operator feedback on whether subscriber stats are essential to have in a standard MIB, and whether enabling/disabling those stats would be problematic for operations and management. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Behave [mailto:behave-bounces@ietf.org] On Behalf Of Tom Taylor > Sent: Friday, February 06, 2015 4:42 PM > To: behave@ietf.org; opsawg@ietf.org > Cc: Tina TSOU > Subject: [BEHAVE] NATV2-MIB: Proposed additional read-write control on > per-subscriber statistics > > draft-perrault-behave-natv2-mib-01 is almost ready. > > I considered in the past and rejected in my own mind a per-subscriber > control on whether statistics are enabled or not for that subscriber. I > rejected it thinking that the impact on processor consumption would be > minimal, after the processor looked up the subscriber data in the first > place. I've changed my mind for two reasons: first, that I probably made > too many assumptions about implementation, and secondly, because the > impact on storage requirements for per-subscriber statistics would be > potentially huge if such a control were available. > > I therefore propose the following: > > 1) In the description of the CGN application scenario (Section 3.4 of > draft-perrault-behave-natv2-mib-00), add the following sentence: > > "An implementation MAY limit the number of subscribers for which > collection of statistics is enabled at any one time." > > 2) Add the following object to natv2SubscriberTable: > > natv2SubscriberCountersEnabled OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "If true(1), accumulation of statistics in the counters for > this subscriber is enabled and the current values of the > counters can be presented to the manager. If false(1) > (default), accumulation of statistics in the counters for > this subscriber is disabled and the values presented to the > manager MUST be zero regardless of their actual value. > Whenever the value of this object changes, > natv2SubscriberDiscontinuityTime MUST be updated to the time > of change." > ::= { natv2SubscriberEntry xx } > > Comments? > > Tom Taylor > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nobody Mon Feb 9 08:57:23 2015 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 28F731A6F3B; Sat, 7 Feb 2015 10:21:28 -0800 (PST) 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 b3SdypozgzGf; Sat, 7 Feb 2015 10:21:26 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 531DD1A6F38; Sat, 7 Feb 2015 10:21:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=a/ehGZMNKKNztf0+rlF+yQpMYikXieacR3KVvyKZI8m0H8WyWggZE9P7gRHSdYHl; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YKA0S-0002Sr-NJ; Sat, 07 Feb 2015 13:21:24 -0500 Received: from 76.254.51.90 by webmail.earthlink.net with HTTP; Sat, 7 Feb 2015 13:21:24 -0500 Message-ID: <21435188.1423333284432.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Sat, 7 Feb 2015 10:21:24 -0800 (GMT-08:00) From: Randy Presuhn To: ietfdbh , 'Tom Taylor' , behave@ietf.org, opsawg@ietf.org 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537b7343701542303123d6069e6d0a6bac0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Archived-At: X-Mailman-Approved-At: Mon, 09 Feb 2015 08:52:30 -0800 Subject: Re: [BEHAVE] [OPSAWG] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics 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: Sat, 07 Feb 2015 18:21:28 -0000 Hi - >From: ietfdbh >Sent: Feb 7, 2015 6:24 AM >To: 'Tom Taylor' , behave@ietf.org, opsawg@ietf.org >Subject: Re: [OPSAWG] [BEHAVE] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics ... >What impact would this on-off discontinuity have on the multiple manager >scenario. What happens if one manager is monitoring a subscriber's stats for >a period of time, and another manager goes in a mucks about with the >continuity of collection? > >SNMP's design of counters - read, then read again and consider the delta, >rather than zeroing counters constantly - is done to support the (very >common) multiple manager scenario. The counters are consistently available, >which is useful for historical trending, etc. The dynamic enable/disable of >collection would seem to defeat that important SNMP design choice, and make >interpretation of the discontinuous values over time more difficult and less >useful. > >So I think there needs to be considerate discussion of the operational >impact of such a switch in this MIB. I think this specific concern could be easily addressed by a read-only object in the table which reports the sysUptime of the most recent change to that row's switch setting or RowStatus. Randy From nobody Tue Feb 17 11:46:00 2015 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 28FE11A1B2F; Tue, 17 Feb 2015 11:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 EBfKZ72s7ShC; Tue, 17 Feb 2015 11:45:53 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB081A0010; Tue, 17 Feb 2015 11:45:53 -0800 (PST) Received: by iecar1 with SMTP id ar1so43590391iec.0; Tue, 17 Feb 2015 11:45:52 -0800 (PST) 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=iQBfKw0O1ixvzLer98vsr/03SEvOsrj53HRoGRfcF3Q=; b=Pjds79FwzyLnRbouSi5AOsGvEJwjKFoe0eP0CQLLlDVIGD3cO2hy9gNSLlHncefQg/ 1eDQuqC0hh0rfaV0iLDfSmXjyo8Ad6vcY4Vo4XDaiyCuPSlrCzDYfY0d0hdy0db+DHkY Uks87leLT0qWzR8fnyH3cj1BwluAes67+BLuwfRP09M4wwfGGKdvZmdS4J/4kh2x17l6 KTalnJY/uKM+ee14pe397xagNlfTnKPvmrycASibduouxH63AqCB/+MNp4Nzup4NSlA7 OVEn0UZpFbH3vOFXROIs/ono1WYlQAhvfN7VAqksMrVE1o6d1S0fDqjwukO+qwGgZD2p ZS7w== X-Received: by 10.107.149.212 with SMTP id x203mr11210471iod.12.1424202352684; Tue, 17 Feb 2015 11:45:52 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-36-51.tor.primus.ca. [173.206.36.51]) by mx.google.com with ESMTPSA id w3sm10716424igz.1.2015.02.17.11.45.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 11:45:52 -0800 (PST) Message-ID: <54E39A6E.2040507@gmail.com> Date: Tue, 17 Feb 2015 14:45:50 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "opsawg@ietf.org" , "behave@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: David Harrington , Spencer Dawkins , "Fuyu \(Eleven\)" Subject: [BEHAVE] Submission of draft-perrault-behave-natv2-mib-01 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, 17 Feb 2015 19:45:58 -0000 I have finished work on draft-perrault-behave-natv2-mib-01 at last. I will follow up with a series of messages proposing parts of the document for review over the next week or so. In the meantime, I'd better learn how to use lint to check the MIB module itself. Changes from the -00 version: ============================ 1. Filled out the Operations and Management Considerations section and updated the Security Considerations section. 2. Renamed: natv2NextProtocolxxx to simply natv2Protocolxxx. 3. Added a few items of terminology to Section 2: "upper layer protocol", "trigger", "report", and "address realm". 4. Added text to the definition of the statistic "Other resource failure drops": "The most likely case would be packets where the upper layer protocol is not one supported by the NAT instance." Dropped this statistic from other levels, reporting it only at the NAT instance level. I notice that I failed to follow through in the Conformance section, so that has to be fixed. 5. Added natv2PortMapExternalPool to the port map table. 6. Renamed: natv2PoolPortMin -> natv2PoolMinimumPort, and similarly for maximum. 7. Added RFCs 2460 and 3489 as references. 3489 was supposed to be informative, but I seem to have put it in the wrong place. That has to be fixed. Tom Taylor From nobody Tue Feb 17 19:22:48 2015 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 27A961A9251; Tue, 17 Feb 2015 19:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 ZYPPSiFWjVKk; Tue, 17 Feb 2015 19:22:42 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F631A86DD; Tue, 17 Feb 2015 19:22:42 -0800 (PST) Received: by iecar1 with SMTP id ar1so45969379iec.0; Tue, 17 Feb 2015 19:22:42 -0800 (PST) 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=j+BrLrpilMW9XqQFahPi5MTFco1um6INQnOEZ5NgmeE=; b=ln+Dw2f1T+r7is6FVWur8aiBIBJZ/mwEriTMu6E7q9rPuNmOURY8cVgpB51KttyRb6 MBFo3wa434dS0s7CUa8+xCM3pts7hYC+lLhsb9X3h0sjNtcNCcG9WX4/V3meeSTG1usc l+zHNga/9r10JlvM852XOlCTupOsaXJ0wU94OuBfYJLjbh1zBq9lJLefLC4ulHTksxq5 YS8bgxvsZ2xpU1D5zp8KkqSTqIq+AilRIcA0Md3nF66nuOvKb+XTN+B87udyOCRbThLn S+ekPl/P4H8T10BK6sSPb/OvVhID1oPE82RrZ/sFYLaac/QJgjzzYwM9nN76dfxh1IbG j4EQ== X-Received: by 10.50.43.162 with SMTP id x2mr451288igl.46.1424229762058; Tue, 17 Feb 2015 19:22:42 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-36-51.tor.primus.ca. [173.206.36.51]) by mx.google.com with ESMTPSA id s17sm11272179igr.2.2015.02.17.19.22.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 19:22:41 -0800 (PST) Message-ID: <54E40579.8060508@gmail.com> Date: Tue, 17 Feb 2015 22:22:33 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "opsawg@ietf.org" , "behave@ietf.org" , Senthil Sivakumar , Simon Perreault , Tina TSOU , Spencer Dawkins Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "fuyu \(Eleven\)" Subject: [BEHAVE] draft-perrault-behave-natv2-mib-02 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, 18 Feb 2015 03:22:47 -0000 I have submitted another update to the NATV2-MIB draft. This corrects the errors noted in my previous E-mail, and also corrects a number of errors in the MIB module that were revealed by the smilint tool. Subject to the results of your review, this draft should be good to go, except that there is a potential sub-identifier issue with the keys to the address and the port map tables that I have to clear with the MIB experts. Tom Taylor From nobody Sun Feb 22 07:52:01 2015 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 DC1A61A1BCB; Sun, 22 Feb 2015 07:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 GhvEuB3vvecZ; Sun, 22 Feb 2015 07:51:59 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994DF1A1BC7; Sun, 22 Feb 2015 07:51:59 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so13218770igb.5; Sun, 22 Feb 2015 07:51:58 -0800 (PST) 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=qcTiJbiwgsuAHbNZdv6xeQvAISUu7oIG1ggctYOnCPY=; b=koifMrudZDBGCkptAlkVmT75ISKJY+zevr2LqXTY8LZ33PjIbb+h5NpYGQnCWAH99m b/JhRl7Xf09zpb+DaH2rThpQS1eIy6S1KgPiCyMjcybY+6l8k7tMY3ufscu4dkL6MawO BigBCFA9l8P3i3cxJZNiiaL6oMFurdtwZPOy8JW9p3S2ifqtDxWXetGrIQA5eojKW2C+ vKIM/q04RdM1FpcLf7YiaXh6KqtHZtt6dlq2ravio+sdHAEBucI3Wg/n9Ctm6EqnyYXV FLlv18ddAmKxuEijy+yCYZVSWn9N+OFFNViuhS5nRIAiw9eRWcz+BtJCVhrBvPR6sbsQ 9G/g== X-Received: by 10.43.34.137 with SMTP id ss9mr7538341icb.11.1424620318830; Sun, 22 Feb 2015 07:51:58 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-74-106.tor.primus.ca. [173.206.74.106]) by mx.google.com with ESMTPSA id t41sm20618989ioi.0.2015.02.22.07.51.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 07:51:58 -0800 (PST) Message-ID: <54E9FB1F.1060401@gmail.com> Date: Sun, 22 Feb 2015 10:51:59 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [BEHAVE] Reviewing draft-perrault-behave-natv2-mib-02 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, 22 Feb 2015 15:52:01 -0000 Could I direct reviewers to Section 3.1.4 of draft-perrault-behave-natv2-mib-02 to start with? Are the statistics described there sufficient for NAT management, and do we have the granularities right? Is there anything we could do without? Tom Taylor