From nobody Sat Jun 6 16:14:13 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 6E4171A1B00; Sat, 6 Jun 2015 16:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 ZfyyZXo_0rMl; Sat, 6 Jun 2015 16:14:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E551A1ADF; Sat, 6 Jun 2015 16:14:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150606231411.18753.26203.idtracker@ietfa.amsl.com> Date: Sat, 06 Jun 2015 16:14:11 -0700 Archived-At: Cc: simon.perreault@viagenie.ca, behave@ietf.org, tina.tsou.zouting@huawei.com, Spencer Dawkins , tom.taylor.stds@gmail.com Subject: [BEHAVE] Barry Leiba's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 23:14:12 -0000 Barry Leiba has entered the following ballot position for draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The IANA Considerations section says there are no IANA actions here. Is that really so? Don't you need to change the reference for the natMIB (123) from RFC4008 to this document? Otherwise, what was the point of replicating the entire MIB and changing the status field of each item to "deprecated"? It's clear that 4008 is no longer the current reference for natMIB. I would actually suggest that you also change the description field for natMIB from "NAT-MIB" to "[deprecated]" or "NAT-MIB [deprecated]". From nobody Sat Jun 6 16:19:02 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 CBEAF1A1B0C; Sat, 6 Jun 2015 16:18:47 -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, 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 nzjmekv7L9Ud; Sat, 6 Jun 2015 16:18:46 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::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 DCA771A1B12; Sat, 6 Jun 2015 16:18:44 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so77987898ieb.0; Sat, 06 Jun 2015 16:18:44 -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=iXc3h1SGBFDhIqJMQbaxfIwGrN6vu2SqEgmMdhuJFNs=; b=MZOtMqAKWZ/mIKmuUbljUUq06iyqYrshUAe60LCY6ycBijQ1j5o5ccLyWPLgrPOv2z yQXrESIVYAK3S81TZ4fY08U5GaLBmXCVQaxrN6waHOxohVRqEvvJqQRVeSAjr1tCBeE5 AyWa1OmH4w8btkoYkRtUiAJKZhAP0k2lx8Ztmy+xYI5MTaMZyjY744VXAaSkGjvwQvbP fOHu7kOQk+/icYcmQXr3N1MmsCruxILYijHqrkTBjtYAgSL24PHNocBXTKxDWNNlvAK5 bcdEKPH8gzT7uLOH9sZH6E3mKd2cWHHiTEW9s7wTefhw7AKuASWGVw1liaTJeFur5hgi MjaQ== X-Received: by 10.42.204.4 with SMTP id fk4mr565943icb.72.1433632724219; Sat, 06 Jun 2015 16:18:44 -0700 (PDT) Received: from [192.168.1.135] ([108.63.153.52]) by mx.google.com with ESMTPSA id x3sm1891878igl.2.2015.06.06.16.18.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jun 2015 16:18:43 -0700 (PDT) Message-ID: <55737FAD.2040304@gmail.com> Date: Sat, 06 Jun 2015 19:18:05 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150606231411.18753.26203.idtracker@ietfa.amsl.com> In-Reply-To: <20150606231411.18753.26203.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: simon.perreault@viagenie.ca, behave@ietf.org, Spencer Dawkins , tina.tsou.zouting@huawei.com Subject: Re: [BEHAVE] Barry Leiba's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS) 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, 06 Jun 2015 23:18:48 -0000 Thanks. I already had this on my to-do list based on IANA's input earlier. I just wasn't sure when to submit the change. Tom Taylor On 06/06/2015 7:14 PM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The IANA Considerations section says there are no IANA actions here. Is > that really so? Don't you need to change the reference for the natMIB > (123) from RFC4008 to this document? Otherwise, what was the point of > replicating the entire MIB and changing the status field of each item to > "deprecated"? It's clear that 4008 is no longer the current reference > for natMIB. > > I would actually suggest that you also change the description field for > natMIB from "NAT-MIB" to "[deprecated]" or "NAT-MIB [deprecated]". > > > > > From nobody Sat Jun 6 16:22:26 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 D90D11A1B24; Sat, 6 Jun 2015 16:22:24 -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] 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 iPaB3om59WKI; Sat, 6 Jun 2015 16:22:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A675F1A1B20; Sat, 6 Jun 2015 16:22:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150606232223.20301.44775.idtracker@ietfa.amsl.com> Date: Sat, 06 Jun 2015 16:22:23 -0700 Archived-At: Cc: simon.perreault@viagenie.ca, behave@ietf.org, tina.tsou.zouting@huawei.com, Spencer Dawkins , tom.taylor.stds@gmail.com Subject: [BEHAVE] Barry Leiba's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 23:22:25 -0000 Barry Leiba has entered the following ballot position for draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The IANA Considerations section says there are no IANA actions here. Is that really so? Don't you need to change the reference for the natMIB (123) from RFC4008 to this document? Otherwise, what was the point of replicating the entire MIB and changing the status field of each item to "deprecated"? It's clear that 4008 is no longer the current reference for natMIB. I would actually suggest that you also change the description field for natMIB from "NAT-MIB" to "[deprecated]" or "NAT-MIB [deprecated]". ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Oh, and I meant to ask: Do the Security Considerations, as written, really apply to this document? Would it, perhaps, be more appropriate for these Security Considerations to say that this MIB Is entirely deprecated, and that the security considerations in draft-perrault-Behave-natv2-mib apply instead, to current nat MIBs? From nobody Sun Jun 7 16:12:33 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 B66571AD369; Sun, 7 Jun 2015 16:12:32 -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 AIHCuakHD2iI; Sun, 7 Jun 2015 16:12:31 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 7D3051AD367; Sun, 7 Jun 2015 16:12:31 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so87286957ieb.0; Sun, 07 Jun 2015 16:12:31 -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=pcG/f8DREAZC4S3FDRQqpyEXBuWlpMOzeZFthyI2f0s=; b=fYWDcmVxVaMW3+hqBLck1d7GtO48yDsIt1NbA/mSpOffa420sFQPtYQz0yfAwX2Bt7 TRvqgfBV5fQMy8LdohIMo2b1GLm+OkVoiOQEugCKNteQSDGHQE8Qp4ZRq1SbWpE11gHB zdzqMXgjs4sqQ81qpsPaTqtFjsYjCOb1Kgj1QmlVM/G2IEDHVsr7Fy7ye5Q13TfooeEl WHxZ/hsPglNFkfUvYGHvRDwcJUYI24QFthE6iCgJhn4lK5BHor+3HdFJdS05MPhzKGWx gSTK0urPM6N+nUEVGFyE4Z5TM40ZfV1cEN0DRrtn799mn1ePxrFf6tN1Tfwlapo2YKyc BtAA== X-Received: by 10.50.178.230 with SMTP id db6mr10145160igc.26.1433718749869; Sun, 07 Jun 2015 16:12:29 -0700 (PDT) Received: from [192.168.1.135] ([108.63.153.52]) by mx.google.com with ESMTPSA id rj5sm2543090igc.2.2015.06.07.16.12.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2015 16:12:28 -0700 (PDT) Message-ID: <5574CFDC.5030108@gmail.com> Date: Sun, 07 Jun 2015 19:12:28 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150606232223.20301.44775.idtracker@ietfa.amsl.com> In-Reply-To: <20150606232223.20301.44775.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: behave@ietf.org, Spencer Dawkins , tina.tsou.zouting@huawei.com Subject: Re: [BEHAVE] Barry Leiba's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 07 Jun 2015 23:12:32 -0000 On 06/06/2015 7:22 PM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss > ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Oh, and I meant to ask: Do the Security Considerations, as written, > really apply to this document? Would it, perhaps, be more appropriate > for these Security Considerations to say that this MIB Is entirely > deprecated, and that the security considerations in > draft-perrault-Behave-natv2-mib apply instead, to current nat MIBs? > > > Agreed. From nobody Sun Jun 7 17:22:53 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 6D0AA1A00F4; Sun, 7 Jun 2015 17:22: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 GNXFt6Yu6LkG; Sun, 7 Jun 2015 17:22:50 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 A9B611A00EA; Sun, 7 Jun 2015 17:22:50 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so52871478ieb.1; Sun, 07 Jun 2015 17:22:50 -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=YLox3pAm2FfSBpj+r91I2/WYgrF3JPcSVPuDq8kzDz8=; b=fR4vbwWrSZpztWKD1l+Rm3iRXGGj3ynqLVkwNV/k0Vbdz8NksmmhGxsU6x8izPPXJg vSFAblhPLO65V1SKswABTkrrpMNEnglBPe0pmHND7Y9VMv7yTcezLcjkZN791pMuKNvR tAn8EabCw6SaxU6kDNpHSB+JZtdSDLacd00LTIdFBedAhGOkQ95IZUdPQyQt+IVtJRb+ 0elUVPvTBbCaiXUUpjcy6ReIr93L0QB98MrujP6fydwJPj/S6A/1cO0YHXzMviHoTfVi OFhxN4zRaJzpVnDivmHSYru+VhAMJ0obi9ZSzi86NPqRIFruMMjS5PGLCRiek4sjR45q ganQ== X-Received: by 10.50.6.76 with SMTP id y12mr10435058igy.31.1433722970113; Sun, 07 Jun 2015 17:22:50 -0700 (PDT) Received: from [192.168.1.135] ([108.63.153.52]) by mx.google.com with ESMTPSA id o200sm726090ioo.43.2015.06.07.17.22.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2015 17:22:49 -0700 (PDT) Message-ID: <5574E059.70308@gmail.com> Date: Sun, 07 Jun 2015 20:22:49 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150606232223.20301.44775.idtracker@ietfa.amsl.com> In-Reply-To: <20150606232223.20301.44775.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: behave@ietf.org, Spencer Dawkins , tina.tsou.zouting@huawei.com Subject: Re: [BEHAVE] Barry Leiba's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 08 Jun 2015 00:22:52 -0000 I've submitted version -02 of this document. It may take a while to show up because I requested a manual posting to fix Simon's address for notifications. Apologies, I missed the final suggestion of your DISCUSS. The changes made were as follows: - removed some unused IMPORTS to make SMILINT happy - updated contact information in the module header - truncated the Security Considerations section as suggested in your comment - added IANA actions as suggested by you and IANA. Tom Taylor On 06/06/2015 7:22 PM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The IANA Considerations section says there are no IANA actions here. Is > that really so? Don't you need to change the reference for the natMIB > (123) from RFC4008 to this document? Otherwise, what was the point of > replicating the entire MIB and changing the status field of each item to > "deprecated"? It's clear that 4008 is no longer the current reference > for natMIB. > > I would actually suggest that you also change the description field for > natMIB from "NAT-MIB" to "[deprecated]" or "NAT-MIB [deprecated]". > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Oh, and I meant to ask: Do the Security Considerations, as written, > really apply to this document? Would it, perhaps, be more appropriate > for these Security Considerations to say that this MIB Is entirely > deprecated, and that the security considerations in > draft-perrault-Behave-natv2-mib apply instead, to current nat MIBs? > > > From nobody Mon Jun 8 02:32:54 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 2F5E21B2DFC; Mon, 8 Jun 2015 02:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 2pNuf7rnhsmt; Mon, 8 Jun 2015 02:32:50 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (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 785221B2DDA; Mon, 8 Jun 2015 02:32:50 -0700 (PDT) Received: by ieclw1 with SMTP id lw1so94115748iec.3; Mon, 08 Jun 2015 02:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9F+AnnILDGkLo2xrbDmyobasbs4J1GXRx9d7DhF8P4E=; b=XmrxdxTaGo/6ERUm6O4955q9rlY31SRV8eOyjwA+xZmrEZZNywqj8wy5ydBpENl9kb Q7vja/hCS5oamcsD2mM/R1jdfF2zvyB+FnaKc6OXN1zoBsUtpPgQv/HyQYUey+dkaIrA 8DMXrx43YJK7/yCpv4pbD7bCWot1eKK9wjBDwMDJuAX7SXvFTKRAoS5oMTXUjnsT0MLc Re5lt2/zjcV4/pel6Sw6KQo/yM4HUVh2PN/Kw9yTAnbtIQstBXZHME9uSTna62fHsa47 R7zGjtyOhx+4sDesF88h9Jsu37WgnurYelxMxNHx03a2/Gar0FxThomzrCj/AHQRMkHX mvtQ== MIME-Version: 1.0 X-Received: by 10.50.4.66 with SMTP id i2mr12333708igi.40.1433755969871; Mon, 08 Jun 2015 02:32:49 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.16.222 with HTTP; Mon, 8 Jun 2015 02:32:49 -0700 (PDT) In-Reply-To: <5574E059.70308@gmail.com> References: <20150606232223.20301.44775.idtracker@ietfa.amsl.com> <5574E059.70308@gmail.com> Date: Mon, 8 Jun 2015 05:32:49 -0400 X-Google-Sender-Auth: 9GOPBXuiA7Wu7xj9XnTH2hdNKA8 Message-ID: From: Barry Leiba To: Tom Taylor Content-Type: multipart/alternative; boundary=001a11c2a6f64768710517fe531f Archived-At: Cc: "behave@ietf.org" , "tina.tsou.zouting@huawei.com" , The IESG , Spencer Dawkins Subject: Re: [BEHAVE] Barry Leiba's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 08 Jun 2015 09:32:52 -0000 --001a11c2a6f64768710517fe531f Content-Type: text/plain; charset=UTF-8 Perfect; thanks. I'll clear the discuss as soon as I get to my hotel, which involves getting through this interminable passport queue at Dublin airport. Barry On Monday, June 8, 2015, Tom Taylor wrote: > I've submitted version -02 of this document. It may take a while to show > up because I requested a manual posting to fix Simon's address for > notifications. > > Apologies, I missed the final suggestion of your DISCUSS. The changes made > were as follows: > > - removed some unused IMPORTS to make SMILINT happy > - updated contact information in the module header > - truncated the Security Considerations section as suggested in your > comment > - added IANA actions as suggested by you and IANA. > > Tom Taylor > > On 06/06/2015 7:22 PM, Barry Leiba wrote: > >> Barry Leiba has entered the following ballot position for >> draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> >> https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> The IANA Considerations section says there are no IANA actions here. Is >> that really so? Don't you need to change the reference for the natMIB >> (123) from RFC4008 to this document? Otherwise, what was the point of >> replicating the entire MIB and changing the status field of each item to >> "deprecated"? It's clear that 4008 is no longer the current reference >> for natMIB. >> >> I would actually suggest that you also change the description field for >> natMIB from "NAT-MIB" to "[deprecated]" or "NAT-MIB [deprecated]". >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Oh, and I meant to ask: Do the Security Considerations, as written, >> really apply to this document? Would it, perhaps, be more appropriate >> for these Security Considerations to say that this MIB Is entirely >> deprecated, and that the security considerations in >> draft-perrault-Behave-natv2-mib apply instead, to current nat MIBs? >> >> >> >> > --001a11c2a6f64768710517fe531f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Perfect; thanks.=C2=A0 I'll clear the discuss as soon as I get to my ho= tel, which involves getting through this interminable passport queue at Dub= lin airport.

Barry

On Monday, June 8= , 2015, Tom Taylor <tom.tay= lor.stds@gmail.com> wrote:
I'v= e submitted version -02 of this document. It may take a while to show up be= cause I requested a manual posting to fix Simon's address for notificat= ions.

Apologies, I missed the final suggestion of your DISCUSS. The changes made = were as follows:

- removed some unused IMPORTS to make SMILINT happy
- updated contact information in the module header
- truncated the Security Considerations section as suggested in your commen= t
- added IANA actions as suggested by you and IANA.

Tom Taylor

On 06/06/2015 7:22 PM, Barry Leiba wrote:
Barry Leiba has entered the following ballot position for
draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-cr= iteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-perr= ault-behave-deprecate-nat-mib-v1/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The IANA Considerations section says there are no IANA actions here.=C2=A0 = Is
that really so?=C2=A0 Don't you need to change the reference for the na= tMIB
(123) from RFC4008 to this document?=C2=A0 Otherwise, what was the point of=
replicating the entire MIB and changing the status field of each item to "deprecated"?=C2=A0 It's clear that 4008 is no longer the cur= rent reference
for natMIB.

I would actually suggest that you also change the description field for
natMIB from "NAT-MIB" to "[deprecated]" or "NAT-MI= B [deprecated]".


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Oh, and I meant to ask: Do the Security Considerations, as written,
really apply to this document?=C2=A0 Would it, perhaps, be more appropriate=
for these Security Considerations to say that this MIB Is entirely
deprecated, and that the security considerations in
draft-perrault-Behave-natv2-mib apply instead, to current nat MIBs?




--001a11c2a6f64768710517fe531f-- From nobody Mon Jun 8 06:41:20 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 BF21A1A8798; Mon, 8 Jun 2015 06:41:19 -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] 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 0C9YB-JZbgiu; Mon, 8 Jun 2015 06:41:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 665ED1A878B; Mon, 8 Jun 2015 06:41:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 06:41:17 -0700 Archived-At: Cc: simon.perreault@viagenie.ca, behave@ietf.org, tina.tsou.zouting@huawei.com, jouni.nospam@gmail.com, Spencer Dawkins , tom.taylor.stds@gmail.com Subject: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 13:41:19 -0000 Benoit Claise has entered the following ballot position for draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This ballot is based on version 1 (I understand that v2 is on its way, waiting for the secretariat to post) - Before deprecating the following textual conventions, have you checked that they are not used in any MIB modules? NatProtocolType ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "A list of protocols that support the network address translation. Inclusion of the values is not intended to imply that those protocols need to be supported. Any change in this TEXTUAL-CONVENTION should also be reflected in the definition of NatProtocolMap, which is a BITS representation of this." SYNTAX INTEGER { none (1), -- not specified other (2), -- none of the following icmp (3), udp (4), tcp (5) } NatProtocolMap ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "A bitmap of protocol identifiers that support the network address translation. Any change in this TEXTUAL-CONVENTION should also be reflected in the definition of NatProtocolType." SYNTAX BITS { other (0), icmp (1), udp (2), tcp (3) } NatAddrMapId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS deprecated DESCRIPTION "A unique id that is assigned to each address map by a NAT enabled device." SYNTAX Unsigned32 (1..4294967295) NatBindIdOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS deprecated DESCRIPTION "A unique id that is assigned to each bind by a NAT enabled device. The bind id will be zero in the case of a Symmetric NAT." SYNTAX Unsigned32 (0..4294967295) NatBindId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS deprecated DESCRIPTION "A unique id that is assigned to each bind by a NAT enabled device." SYNTAX Unsigned32 (1..4294967295) NatSessionId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS deprecated DESCRIPTION "A unique id that is assigned to each session by a NAT enabled device." SYNTAX Unsigned32 (1..4294967295) NatBindMode ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "An indication of whether the bind is an address bind or an address port bind." SYNTAX INTEGER { addressBind (1), addressPortBind (2) } NatAssociationType ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "An indication of whether the association is static or dynamic." SYNTAX INTEGER { static (1), dynamic (2) } NatTranslationEntity ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "An indication of a) the direction of a session for which an address map entry, address bind or port bind is applicable, and b) the entity (source or destination) within the session that is subject to translation." SYNTAX BITS { inboundSrcEndPoint (0), outboundDstEndPoint(1), inboundDstEndPoint (2), outboundSrcEndPoint(3) } This is currently in discussion with the MIB doctors (draft authors are copied) At the very minimum, a note in an "operations considerations" section, explaining the implications of removing TCs, is required - This point above is in line with Jouni's feedback. * There is also no text about operational and management implications related to deprecation process of the old MIB and migrating to the new (to be approved) NAT-MIB-v2). - Let me check something. As noted by Jouni in his OPS-DIR review, The smilint reports the following warnings: * mibs/NAT-MIB:15: [5] {import-unused} warning: identifier `DisplayString' imported from module `SNMPv2-TC' is never used * mibs/NAT-MIB:27: [5] {import-unused} warning: identifier `InterfaceIndex' imported from module `IF-MIB' is never used * mibs/NAT-MIB:33: [5] {import-unused} warning: identifier `InetAddressPrefixLength' imported from module `INET-ADDRESS-MIB' is never used * mibs/NAT-MIB:36: [5] {import-unused} warning: identifier `VPNIdOrZero' imported from module `VPN-TC-STD-MIB' is never used My first reaction: it's normal because some objects are now deprecated (so not used any longer). After some analysis ... When comparing the imports lines from RFC4008 and the ones from this draft, those 4 lines magically appeared in this draft. Why? This asks the question: have you actually started your work from the MIB module extracted from RFC4008? I started to file a DISCUSS on that very point. However, I was so bothered by this difference that I actually compared the MIB modules extracted from this draft and from RFC4008. I see two occurences of this change: InetAddress (SIZE (4|16) versus InetAddress Why? Also, I wanted to check this condition in RFC4181: - On the other hand, the module name MUST NOT be changed (except to correct typographical errors), existing definitions (even obsolete ones) MUST NOT be removed from the MIB module, and descriptors and OBJECT IDENTIFIER values associated with existing definitions MUST NOT be changed or re-assigned. A word expressing that all RFC 4008 MIB objects are included in this version, but with only the STATUS changed to deprecated would be helpful. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - A point mentioned by Jouni that might be elevated to a DISCUSS (I let the security ADs decide): * The Security Considerations does not really discuss the security implications of the _deprecation_ itself e.g. there is going to be boxes out there that use the old MIB and others that use the new (to be approved) MIB and what that mixed environment might entail. There is some text that is getting to that direction (SNMPv2 and SNMPv3 security differences). * Since the new MIB is kind of requirement for replacing this old to be deprecated MIB, I would assume the draft-ietf-behave-nat-mib-v2 to be a _normative_ reference in this document. EDITORIAL * change the copyright date to 2015 * Unused Reference: 'RFC4787' is defined, but no reference was found in the text. * SNMP acronym is the first time used in Section 1 unexpaned. The acronym is expanded later in Section 2. Expand it already in Section 1. From nobody Mon Jun 8 08:14:28 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 BFA5E1B2ECA; Mon, 8 Jun 2015 08:14:25 -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] 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 fu07ISgwxQbE; Mon, 8 Jun 2015 08:14:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 620351B2EF8; Mon, 8 Jun 2015 08:11:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608151137.12476.47325.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 08:11:37 -0700 Archived-At: Cc: simon.perreault@viagenie.ca, behave@ietf.org, tina.tsou.zouting@huawei.com, Spencer Dawkins , tom.taylor.stds@gmail.com Subject: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:14:25 -0000 Benoit Claise has entered the following ballot position for draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This ballot is based on version 1 (I understand that v2 is on its way, waiting for the secretariat to post) - Jouni's feedback. * There is also no text about operational and management implications related to deprecation process of the old MIB and migrating to the new (to be approved) NAT-MIB-v2). See the discussion captured on the MIB-doctors list. - Let me check something. As noted by Jouni in his OPS-DIR review, The smilint reports the following warnings: * mibs/NAT-MIB:15: [5] {import-unused} warning: identifier `DisplayString' imported from module `SNMPv2-TC' is never used * mibs/NAT-MIB:27: [5] {import-unused} warning: identifier `InterfaceIndex' imported from module `IF-MIB' is never used * mibs/NAT-MIB:33: [5] {import-unused} warning: identifier `InetAddressPrefixLength' imported from module `INET-ADDRESS-MIB' is never used * mibs/NAT-MIB:36: [5] {import-unused} warning: identifier `VPNIdOrZero' imported from module `VPN-TC-STD-MIB' is never used My first reaction: it's normal because some objects are now deprecated (so not used any longer). After some analysis ... When comparing the imports lines from RFC4008 and the ones from this draft, those 4 lines magically appeared in this draft. Why? This asks the question: have you actually started your work from the MIB module extracted from RFC4008? I started to file a DISCUSS on that very point. However, I was so bothered by this difference that I actually compared the MIB modules extracted from this draft and from RFC4008. I see two occurences of this change: InetAddress (SIZE (4|16) versus InetAddress Why? Also, I wanted to check this condition in RFC4181: - On the other hand, the module name MUST NOT be changed (except to correct typographical errors), existing definitions (even obsolete ones) MUST NOT be removed from the MIB module, and descriptors and OBJECT IDENTIFIER values associated with existing definitions MUST NOT be changed or re-assigned. A word expressing that all RFC 4008 MIB objects are included in this version, but with only the STATUS changed to deprecated would be helpful. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - A point mentioned by Jouni that might be elevated to a DISCUSS (I let the security ADs decide): * The Security Considerations does not really discuss the security implications of the _deprecation_ itself e.g. there is going to be boxes out there that use the old MIB and others that use the new (to be approved) MIB and what that mixed environment might entail. There is some text that is getting to that direction (SNMPv2 and SNMPv3 security differences). * Since the new MIB is kind of requirement for replacing this old to be deprecated MIB, I would assume the draft-ietf-behave-nat-mib-v2 to be a _normative_ reference in this document. EDITORIAL * change the copyright date to 2015 * Unused Reference: 'RFC4787' is defined, but no reference was found in the text. * SNMP acronym is the first time used in Section 1 unexpaned. The acronym is expanded later in Section 2. Expand it already in Section 1. From nobody Mon Jun 8 09:00:55 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 0751A1B2FEA for ; Mon, 8 Jun 2015 09:00:46 -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] 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 8GwrjCzVrlcT; Mon, 8 Jun 2015 09:00:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0027B1B2FD1; Mon, 8 Jun 2015 09:00:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , "Spencer Dawkins" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608160010.10044.98116.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 09:00:10 -0700 Archived-At: Subject: [BEHAVE] New Version Notification - draft-perrault-behave-deprecate-nat-mib-v1-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 16:00:46 -0000 A new version (-02) has been submitted for draft-perrault-behave-deprecate-nat-mib-v1: https://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02 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. IETF Secretariat. From nobody Mon Jun 8 10:15:33 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 244801AC3D4 for ; Mon, 8 Jun 2015 10:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] 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 Q2fg_WadDENQ for ; Mon, 8 Jun 2015 10:15:22 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C821AC3BF for ; Mon, 8 Jun 2015 10:15:22 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-03v.sys.comcast.net with comcast id dtE31q00A2PT3Qt01tFMDJ; Mon, 08 Jun 2015 17:15:21 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-ch2-14v.sys.comcast.net with comcast id dtFL1q0032yZEBF01tFLUP; Mon, 08 Jun 2015 17:15:21 +0000 From: "ietfdbh" To: "'Benoit Claise'" , "'The IESG'" References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> In-Reply-To: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> Date: Mon, 8 Jun 2015 13:15:20 -0400 Message-ID: <001501d0a20e$b31c90e0$1955b2a0$@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: AQE8SDcWWctaN8P1aLX/Muo/6+XcOZ7LcV9A Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1433783721; bh=RCmK0K06vZX1+YfZ3TOM+DFrhYdYrN2G/powPQ49+Vo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=jgtKFITrF/2YJaFFYLDFxi1uNZ80j2N0mS0HbJQHsivlQD+LQlik0931JgO6dui+R KZr/j9hfLjPReQLgys97KsRVXmeYINklwLT+5MVCmowGlfIyue9jbh9Vn2FiAKSTjW aX8PAzryRE/5gLbObndMedh33Rkxmh3mdEcBxqijGZc4rVOc2j2VtOr3N/3KNjiR97 kjiJEqV16vEuIkY0SzuDOlp4+Vq5nH3RNIBZDyZtMDWP2MG5HxmXFEEXud4MxbLFoW p/XQoiY8GFWlAqethwBYMKGgXBb5N4d8d2tTbIPGsSSNhObVSPqZHU+7oJ02dDom4S KZqrKYHj84BpA== Archived-At: Cc: simon.perreault@viagenie.ca, behave@ietf.org, tina.tsou.zouting@huawei.com, jouni.nospam@gmail.com, 'Spencer Dawkins' , tom.taylor.stds@gmail.com Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 08 Jun 2015 17:15:29 -0000 Hi, Some historical connect: The NAT-MIB was designed largely to be a NAT configuration MIB, back when it was hoped the security features of snmpv3 would make configuration using snmp more tenable. In reality, the complexity of snmpv3 security, and the continuation of snmp being listed as a top-ten vulnerability, discouraged people from moving to it quickly, and the other difficulties of snmp led to Netconf being started, and SNMP being identified a reasonable choice for monitoring, but not configuration. So the nat-mib was overtaken by events related to IETF management protocols. RFC4008 was treated as an individual submission after the NAT WG closed, and it was reviewed by the MIDCOM WG. The IESG questioned whether NAT-MIB should be an IETF standard, because the official IETF stance at the time of IESG review was "NATs are bad; use IPv6". See comments for RFC4008. So RFC4008 never had strong support from the IETF community. Other technologies for working with NATs, such as STUN and TURN and ICE, were already gaining traction by the time the nat-mib was approved. I think Jon Peterson was one of the transport ADs at the time, and working for a service provider that used NATs. I recall him saying when the mib module was approved that he was glad the MIB work was finally completed so the community could focus on USEFUL approaches to nats and stop dealing with the NAT-MIB module. So the NAT-MIB was overtaken by NAT-related events even before its approval. NATs have had so many varieties, the behave WG was created to try to get all the various NAT approaches to work together better. The configuration approach of the nat-mib only addressed a subset of available NATs. So the nat-mib never got much implementation support, and the behave WG checked and found few implementations. Re: normative I think this module can be deprecated without any reference to natv2. I think having a reference to natv2 is useful (and informational). I believe this relationship is not normative because the nat-mib can be implemented without implementing natv2-mib. The nat-mib can likewise be deprecated without implementing the natv2-mib. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Behave [mailto:behave-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Monday, June 08, 2015 9:41 AM > To: The IESG > Cc: simon.perreault@viagenie.ca; behave@ietf.org; > tina.tsou.zouting@huawei.com; jouni.nospam@gmail.com; Spencer > Dawkins; tom.taylor.stds@gmail.com > Subject: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave- > deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) > > Benoit Claise has entered the following ballot position for > draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib- > v1/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This ballot is based on version 1 (I understand that v2 is on its way, > waiting for the secretariat to post) > > - Before deprecating the following textual conventions, have you checked > that they are not used in any MIB modules? > > NatProtocolType ::= TEXTUAL-CONVENTION > STATUS deprecated > DESCRIPTION > "A list of protocols that support the network > address translation. Inclusion of the values is > not intended to imply that those protocols > need to be supported. Any change in this > TEXTUAL-CONVENTION should also be reflected in > the definition of NatProtocolMap, which is a > BITS representation of this." > SYNTAX INTEGER { > none (1), -- not specified > other (2), -- none of the following > icmp (3), > udp (4), > tcp (5) > } > > NatProtocolMap ::= TEXTUAL-CONVENTION > STATUS deprecated > DESCRIPTION > "A bitmap of protocol identifiers that support > the network address translation. Any change > in this TEXTUAL-CONVENTION should also be > reflected in the definition of NatProtocolType." > SYNTAX BITS { > other (0), > icmp (1), > udp (2), > tcp (3) > } > > NatAddrMapId ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS deprecated > DESCRIPTION > "A unique id that is assigned to each address map > by a NAT enabled device." > SYNTAX Unsigned32 (1..4294967295) > > NatBindIdOrZero ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS deprecated > DESCRIPTION > "A unique id that is assigned to each bind by > a NAT enabled device. The bind id will be zero > in the case of a Symmetric NAT." > SYNTAX Unsigned32 (0..4294967295) > > NatBindId ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS deprecated > DESCRIPTION > "A unique id that is assigned to each bind by > a NAT enabled device." > SYNTAX Unsigned32 (1..4294967295) > > NatSessionId ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS deprecated > DESCRIPTION > "A unique id that is assigned to each session by > a NAT enabled device." > SYNTAX Unsigned32 (1..4294967295) > > NatBindMode ::= TEXTUAL-CONVENTION > STATUS deprecated > DESCRIPTION > "An indication of whether the bind is > an address bind or an address port bind." > SYNTAX INTEGER { > addressBind (1), > addressPortBind (2) > } > > NatAssociationType ::= TEXTUAL-CONVENTION > STATUS deprecated > DESCRIPTION > "An indication of whether the association is > static or dynamic." > SYNTAX INTEGER { > static (1), > dynamic (2) > } > > NatTranslationEntity ::= TEXTUAL-CONVENTION > STATUS deprecated > DESCRIPTION > "An indication of a) the direction of a session for > which an address map entry, address bind or port > bind is applicable, and b) the entity (source or > destination) within the session that is subject to > translation." > SYNTAX BITS { > inboundSrcEndPoint (0), > outboundDstEndPoint(1), > inboundDstEndPoint (2), > outboundSrcEndPoint(3) > } > > This is currently in discussion with the MIB doctors (draft authors are > copied) > At the very minimum, a note in an "operations considerations" section, > explaining the implications of removing TCs, is required > > - This point above is in line with Jouni's feedback. > * There is also no text about operational and management implications > related to deprecation process of the old MIB and migrating to the > new (to be approved) NAT-MIB-v2). > > - Let me check something. > As noted by Jouni in his OPS-DIR review, > > The smilint reports the following warnings: > > * mibs/NAT-MIB:15: [5] {import-unused} warning: identifier > `DisplayString' imported from module `SNMPv2-TC' is never used > * mibs/NAT-MIB:27: [5] {import-unused} warning: identifier > `InterfaceIndex' imported from module `IF-MIB' is never used > * mibs/NAT-MIB:33: [5] {import-unused} warning: identifier > `InetAddressPrefixLength' imported from module `INET-ADDRESS-MIB' is > never used > * mibs/NAT-MIB:36: [5] {import-unused} warning: identifier > `VPNIdOrZero' imported from module `VPN-TC-STD-MIB' is never used > > My first reaction: it's normal because some objects are now deprecated > (so not used any longer). > After some analysis ... When comparing the imports lines from RFC4008 and > the ones from this draft, those 4 lines magically appeared in this draft. > Why? > This asks the question: have you actually started your work from the MIB > module extracted from RFC4008? > > I started to file a DISCUSS on that very point. However, I was so > bothered by this difference that I actually compared the MIB modules > extracted from this draft and from RFC4008. > I see two occurences of this change: InetAddress (SIZE (4|16) versus > InetAddress > Why? > > Also, I wanted to check this condition in RFC4181: > > - On the other hand, the module name MUST NOT be changed (except to > correct typographical errors), existing definitions (even obsolete > ones) MUST NOT be removed from the MIB module, and descriptors and > OBJECT IDENTIFIER values associated with existing definitions MUST > NOT be changed or re-assigned. > > A word expressing that all RFC 4008 MIB objects are included in this > version, but with only the STATUS changed to deprecated would be helpful. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - A point mentioned by Jouni that might be elevated to a DISCUSS (I let > the security ADs decide): > * The Security Considerations does not really discuss the security > implications of the _deprecation_ itself e.g. there is going to be > boxes out there that use the old MIB and others that use the new > (to be approved) MIB and what that mixed environment might entail. > There is some text that is getting to that direction (SNMPv2 and > SNMPv3 security differences). > > * Since the new MIB is kind of requirement for replacing this old > to be deprecated MIB, I would assume the draft-ietf-behave-nat-mib-v2 > to be a _normative_ reference in this document. > > EDITORIAL > > * change the copyright date to 2015 > > * Unused Reference: 'RFC4787' is defined, but no reference was found > in the text. > > * SNMP acronym is the first time used in Section 1 unexpaned. The > acronym is expanded later in Section 2. Expand it already in > Section 1. > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nobody Mon Jun 8 12:19: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 D7C211B3238; Mon, 8 Jun 2015 12:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 kWVprOcqIHiB; Mon, 8 Jun 2015 12:18:54 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6371B31F5; Mon, 8 Jun 2015 12:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12346; q=dns/txt; s=iport; t=1433791133; x=1435000733; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mkmBes3307rl7YIfKj8gPe5/60GqXIAuFuJNaLVYM1A=; b=ZG8E/UFDkwJTiO9I25g4dlQm8Hj0lhljZdy69BmUr/IOtHp/cYTs/yvx 14mybFtN4TgVeLZzPz8KzgobdoEh/igBXpG2Kkgs4lFwVnpPf6DO6jp1u ZuuTQYDYE/I0rbbCJRxJG4NFNielN5q7r1s131v1/9aLLeiuaEGI63Lw5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DXAwBU6XVV/xbLJq1ZA4NkXr51CYFTDIUtSgKBYxQBAQEBAQEBgQqEIgEBAQQBAQE1NAIEBgEMBAsRBAEBCgwKBAQHCQMCAQIBDwYfCQgGAQwBBQIBARCIBAMSDcg4CAWFKgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OCTYFVAREBQRAHBgQHhBwBBIZuhHOEcIcdhQqBYIEvg3qCXoEOhz6DMYNZJGGBLRcVgT88MQGBC4E7AQEB X-IronPort-AV: E=Sophos;i="5.13,574,1427760000"; d="scan'208";a="511354671" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 08 Jun 2015 19:18:49 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t58JInGu013439; Mon, 8 Jun 2015 19:18:49 GMT Message-ID: <5575EA98.1080009@cisco.com> Date: Mon, 08 Jun 2015 21:18:48 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: ietfdbh , "'The IESG'" References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> In-Reply-To: <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: simon.perreault@viagenie.ca, behave@ietf.org, tina.tsou.zouting@huawei.com, jouni.nospam@gmail.com, 'Spencer Dawkins' , tom.taylor.stds@gmail.com Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 08 Jun 2015 19:18:57 -0000 Thanks Dave for the background information. From this, I draw two conclusions: - RFC 4008 not implementated. Taking into account the MIB doctor discussion about the deprecated versus obsolete Textual Conventions, I removed the TC point from my DISCUSS (done already +/- 4 hours ago, so you should have received an updated DISCUSS. - you convinced me that the reference doesn't have to be normative. Thanks, Benoit > Hi, > > Some historical connect: > > The NAT-MIB was designed largely to be a NAT configuration MIB, back when it > was hoped the security features of snmpv3 would make configuration using > snmp more tenable. > In reality, the complexity of snmpv3 security, and the continuation of snmp > being listed as a top-ten vulnerability, discouraged people from moving to > it quickly, and the other difficulties of snmp led to Netconf being started, > and SNMP being identified a reasonable choice for monitoring, but not > configuration. > So the nat-mib was overtaken by events related to IETF management protocols. > > RFC4008 was treated as an individual submission after the NAT WG closed, and > it was reviewed by the MIDCOM WG. > The IESG questioned whether NAT-MIB should be an IETF standard, because the > official IETF stance at the time of IESG review was "NATs are bad; use > IPv6". > See comments for RFC4008. > So RFC4008 never had strong support from the IETF community. > > Other technologies for working with NATs, such as STUN and TURN and ICE, > were already gaining traction by the time the nat-mib was approved. > I think Jon Peterson was one of the transport ADs at the time, and working > for a service provider that used NATs. > I recall him saying when the mib module was approved that he was glad the > MIB work was finally completed so the community could focus on USEFUL > approaches to nats and stop dealing with the NAT-MIB module. > So the NAT-MIB was overtaken by NAT-related events even before its approval. > > NATs have had so many varieties, the behave WG was created to try to get all > the various NAT approaches to work together better. > The configuration approach of the nat-mib only addressed a subset of > available NATs. > So the nat-mib never got much implementation support, and the behave WG > checked and found few implementations. > > Re: normative > > I think this module can be deprecated without any reference to natv2. > I think having a reference to natv2 is useful (and informational). > I believe this relationship is not normative because the nat-mib can be > implemented without implementing natv2-mib. > The nat-mib can likewise be deprecated without implementing the natv2-mib. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: Behave [mailto:behave-bounces@ietf.org] On Behalf Of Benoit Claise >> Sent: Monday, June 08, 2015 9:41 AM >> To: The IESG >> Cc: simon.perreault@viagenie.ca; behave@ietf.org; >> tina.tsou.zouting@huawei.com; jouni.nospam@gmail.com; Spencer >> Dawkins; tom.taylor.stds@gmail.com >> Subject: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave- >> deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) >> >> Benoit Claise has entered the following ballot position for >> draft-perrault-behave-deprecate-nat-mib-v1-01: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib- >> v1/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This ballot is based on version 1 (I understand that v2 is on its way, >> waiting for the secretariat to post) >> >> - Before deprecating the following textual conventions, have you checked >> that they are not used in any MIB modules? >> >> NatProtocolType ::= TEXTUAL-CONVENTION >> STATUS deprecated >> DESCRIPTION >> "A list of protocols that support the network >> address translation. Inclusion of the values is >> not intended to imply that those protocols >> need to be supported. Any change in this >> TEXTUAL-CONVENTION should also be reflected in >> the definition of NatProtocolMap, which is a >> BITS representation of this." >> SYNTAX INTEGER { >> none (1), -- not specified >> other (2), -- none of the following >> icmp (3), >> udp (4), >> tcp (5) >> } >> >> NatProtocolMap ::= TEXTUAL-CONVENTION >> STATUS deprecated >> DESCRIPTION >> "A bitmap of protocol identifiers that support >> the network address translation. Any change >> in this TEXTUAL-CONVENTION should also be >> reflected in the definition of NatProtocolType." >> SYNTAX BITS { >> other (0), >> icmp (1), >> udp (2), >> tcp (3) >> } >> >> NatAddrMapId ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "d" >> STATUS deprecated >> DESCRIPTION >> "A unique id that is assigned to each address map >> by a NAT enabled device." >> SYNTAX Unsigned32 (1..4294967295) >> >> NatBindIdOrZero ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "d" >> STATUS deprecated >> DESCRIPTION >> "A unique id that is assigned to each bind by >> a NAT enabled device. The bind id will be zero >> in the case of a Symmetric NAT." >> SYNTAX Unsigned32 (0..4294967295) >> >> NatBindId ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "d" >> STATUS deprecated >> DESCRIPTION >> "A unique id that is assigned to each bind by >> a NAT enabled device." >> SYNTAX Unsigned32 (1..4294967295) >> >> NatSessionId ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "d" >> STATUS deprecated >> DESCRIPTION >> "A unique id that is assigned to each session by >> a NAT enabled device." >> SYNTAX Unsigned32 (1..4294967295) >> >> NatBindMode ::= TEXTUAL-CONVENTION >> STATUS deprecated >> DESCRIPTION >> "An indication of whether the bind is >> an address bind or an address port bind." >> SYNTAX INTEGER { >> addressBind (1), >> addressPortBind (2) >> } >> >> NatAssociationType ::= TEXTUAL-CONVENTION >> STATUS deprecated >> DESCRIPTION >> "An indication of whether the association is >> static or dynamic." >> SYNTAX INTEGER { >> static (1), >> dynamic (2) >> } >> >> NatTranslationEntity ::= TEXTUAL-CONVENTION >> STATUS deprecated >> DESCRIPTION >> "An indication of a) the direction of a session for >> which an address map entry, address bind or port >> bind is applicable, and b) the entity (source or >> destination) within the session that is subject to >> translation." >> SYNTAX BITS { >> inboundSrcEndPoint (0), >> outboundDstEndPoint(1), >> inboundDstEndPoint (2), >> outboundSrcEndPoint(3) >> } >> >> This is currently in discussion with the MIB doctors (draft authors are >> copied) >> At the very minimum, a note in an "operations considerations" section, >> explaining the implications of removing TCs, is required >> >> - This point above is in line with Jouni's feedback. >> * There is also no text about operational and management implications >> related to deprecation process of the old MIB and migrating to the >> new (to be approved) NAT-MIB-v2). >> >> - Let me check something. >> As noted by Jouni in his OPS-DIR review, >> >> The smilint reports the following warnings: >> >> * mibs/NAT-MIB:15: [5] {import-unused} warning: identifier >> `DisplayString' imported from module `SNMPv2-TC' is never used >> * mibs/NAT-MIB:27: [5] {import-unused} warning: identifier >> `InterfaceIndex' imported from module `IF-MIB' is never used >> * mibs/NAT-MIB:33: [5] {import-unused} warning: identifier >> `InetAddressPrefixLength' imported from module `INET-ADDRESS-MIB' is >> never used >> * mibs/NAT-MIB:36: [5] {import-unused} warning: identifier >> `VPNIdOrZero' imported from module `VPN-TC-STD-MIB' is never used >> >> My first reaction: it's normal because some objects are now deprecated >> (so not used any longer). >> After some analysis ... When comparing the imports lines from RFC4008 and >> the ones from this draft, those 4 lines magically appeared in this draft. >> Why? >> This asks the question: have you actually started your work from the MIB >> module extracted from RFC4008? >> >> I started to file a DISCUSS on that very point. However, I was so >> bothered by this difference that I actually compared the MIB modules >> extracted from this draft and from RFC4008. >> I see two occurences of this change: InetAddress (SIZE (4|16) versus >> InetAddress >> Why? >> >> Also, I wanted to check this condition in RFC4181: >> >> - On the other hand, the module name MUST NOT be changed (except to >> correct typographical errors), existing definitions (even obsolete >> ones) MUST NOT be removed from the MIB module, and descriptors and >> OBJECT IDENTIFIER values associated with existing definitions MUST >> NOT be changed or re-assigned. >> >> A word expressing that all RFC 4008 MIB objects are included in this >> version, but with only the STATUS changed to deprecated would be helpful. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - A point mentioned by Jouni that might be elevated to a DISCUSS (I let >> the security ADs decide): >> * The Security Considerations does not really discuss the security >> implications of the _deprecation_ itself e.g. there is going to be >> boxes out there that use the old MIB and others that use the new >> (to be approved) MIB and what that mixed environment might entail. >> There is some text that is getting to that direction (SNMPv2 and >> SNMPv3 security differences). >> >> * Since the new MIB is kind of requirement for replacing this old >> to be deprecated MIB, I would assume the draft-ietf-behave-nat-mib-v2 >> to be a _normative_ reference in this document. >> >> EDITORIAL >> >> * change the copyright date to 2015 >> >> * Unused Reference: 'RFC4787' is defined, but no reference was found >> in the text. >> >> * SNMP acronym is the first time used in Section 1 unexpaned. The >> acronym is expanded later in Section 2. Expand it already in >> Section 1. >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > . > From nobody Wed Jun 10 08:24:07 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 81C051A90A8; Tue, 9 Jun 2015 18:42:11 -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] 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 cxcSvOPa89_l; Tue, 9 Jun 2015 18:42:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0051A90A5; Tue, 9 Jun 2015 18:42:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610014210.9454.52829.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 18:42:10 -0700 Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 08:24:05 -0700 Cc: simon.perreault@viagenie.ca, behave@ietf.org, tina.tsou.zouting@huawei.com, Spencer Dawkins , tom.taylor.stds@gmail.com Subject: [BEHAVE] Ben Campbell's No Objection on draft-perrault-behave-deprecate-nat-mib-v1-02: (with COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 01:42:11 -0000 Ben Campbell has entered the following ballot position for draft-perrault-behave-deprecate-nat-mib-v1-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I concur with Joel's comment about including the entire definition. I was rather surprised to find such a draft requires 57 pages. I concur with Benoit's and Barry's comments that the security considerations aren't really the considerations for _this_ draft. From nobody Wed Jun 10 08:24:24 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 5C0881A90A1; Tue, 9 Jun 2015 18:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 X8iT2lhXky13; Tue, 9 Jun 2015 18:46:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0001A8762; Tue, 9 Jun 2015 18:46:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610014643.9513.6992.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 18:46:43 -0700 Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 08:24:22 -0700 Cc: simon.perreault@viagenie.ca, behave@ietf.org, tina.tsou.zouting@huawei.com, Spencer Dawkins , tom.taylor.stds@gmail.com Subject: [BEHAVE] Kathleen Moriarty's No Objection on draft-perrault-behave-deprecate-nat-mib-v1-02: (with COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 01:46:44 -0000 Kathleen Moriarty has entered the following ballot position for draft-perrault-behave-deprecate-nat-mib-v1-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Barry's last comment on the security considerations text. SInce this draft has no security considerations, it doesn't need to point to the v2 draft for this work. Either saying this draft has no considerations because it deprecates a mib is fine or say that the updated v2 covers security considerations for that nat mib. From nobody Thu Jun 11 08:18:22 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 391AE1B2B45 for ; Thu, 11 Jun 2015 08:18:21 -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] 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 gXFTQ7DEC0Di; Thu, 11 Jun 2015 08:18:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC831B29D0; Thu, 11 Jun 2015 08:18:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Spencer Dawkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150611151819.31125.10470.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 08:18:19 -0700 From: IETF Secretariat Archived-At: Subject: [BEHAVE] ID Tracker State Update Notice: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 15:18:21 -0000 IESG state changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Evaluation - Defer ID Tracker URL: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ From nobody Thu Jun 11 09:40:02 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E2DF51B2F0C; Thu, 11 Jun 2015 03:31:33 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67481B2F05; Thu, 11 Jun 2015 03:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 R3fxqoRkL3pi; Thu, 11 Jun 2015 03:31:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8389F1B2EF8; Thu, 11 Jun 2015 03:31:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CFB992CED4; Thu, 11 Jun 2015 13:31:22 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsYxYt-EQugD; Thu, 11 Jun 2015 13:31:21 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 08B192CEB6; Thu, 11 Jun 2015 13:31:21 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4F4E826A-4F7E-454C-8E44-F0A2C18A5A64"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Jari Arkko In-Reply-To: Date: Thu, 11 Jun 2015 13:31:20 +0300 Message-Id: <75B3536E-448D-42A0-B6A6-7588EEC6E149@piuha.net> References: To: Suresh Krishnan X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Thu, 11 Jun 2015 09:39:52 -0700 Cc: "draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org" , General Area Review Team Subject: Re: [BEHAVE] [Gen-art] Gen-ART Last Call review of draft-perrault-behave-deprecate-nat-mib-v1-01.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: Thu, 11 Jun 2015 10:31:34 -0000 --Apple-Mail=_4F4E826A-4F7E-454C-8E44-F0A2C18A5A64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for your review, Suresh! On 30 Apr 2015, at 07:43, Suresh Krishnan = wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-perrault-behave-deprecate-nat-mib-v1-01.txt > Reviewer: Suresh Krishnan > Review Date: 2015-04-29 > IETF LC End Date: 2015-04-29 >=20 > Summary: This draft is ready for publication as a Proposed Standard. >=20 > Thanks > Suresh >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_4F4E826A-4F7E-454C-8E44-F0A2C18A5A64 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVeWN4AAoJEM80gCTQU46qwl8P/0/tnOU0A52JdFgF7Me6lkvt d1C3ZjtM4RbsgifoxFhQthLUSDcgpd0dtsy0UsuRnRcjTxQjk0MO6qe7/qCDqNXe kIV3ITFjyzVOL/8kdaE5uNelDbblBpNdmpTJjiU/B5OhYTB5HWDf+t6BIxPv5uJj voo4WxJUZeg4jM5r/nBzQ+A81Dqu0cKJPRRIexpFcOVPyO90H0nMYsrPxREWNIXX 6+jeNjfXtW/RKq0YrogcCDUn+ey5Cf8+bIEADZxDNqxDpagX3jOek932R0f+jMvq 5YUSfNbIr9w35lB6vwTmLagnsI/O+918kchi2kAmqhqwJ6XHhYfYaGvMdIpyjom+ d55ewugfX4jMVRShRCDXAqWx6Ek3YbkyRtjXQoTD59UnAkstMhaB5tc3SboYyFgA X7ax6nzfSa2D+3Q0KYgqv46nlP0vYPfzPZ4ZYHkuVtq6AFXEiqDPRHyTS9ahSc5i aGhHLmwviEQCfWTAdPy9Yl4EREPvb3fdgh23BbMzAZAVz5OgLHcANvRp9LDse+et tYrVrXjKmmYCdBeqe3Cmwuier9vpVorxdWmNKcDytGfqMNot+vDIbns9au17COrR 4Rgu0lIrvWaY12KUdxoNxVDNUlIg6629Eg+tQEYCatwlOdxezlHJFyPl6vNgUELZ VdnJrLBlb6uICKy5sEvJ =uaIc -----END PGP SIGNATURE----- --Apple-Mail=_4F4E826A-4F7E-454C-8E44-F0A2C18A5A64-- From nobody Fri Jun 12 07:25:50 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 019791ACC83; Fri, 12 Jun 2015 07:25:49 -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] 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 tcOWWcnkbQMt; Fri, 12 Jun 2015 07:25:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE6C1A1BAF; Fri, 12 Jun 2015 07:25:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612142547.30409.93332.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 07:25:47 -0700 Archived-At: Cc: simon.perreault@viagenie.ca, behave@ietf.org, tina.tsou.zouting@huawei.com, Spencer Dawkins , tom.taylor.stds@gmail.com, ietfdbh@comcast.net Subject: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-02: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 14:25:49 -0000 Benoit Claise has entered the following ballot position for draft-perrault-behave-deprecate-nat-mib-v1-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated based on version 2. - Jouni's feedback. * There is also no text about operational and management implications related to deprecation process of the old MIB and migrating to the new (to be approved) NAT-MIB-v2). Inserting a few lines that there are not implementations (as mentioned by Dave H.) would be sufficient. Dave's messages copied here for your convenience: The NAT-MIB was designed largely to be a NAT configuration MIB, back when it was hoped the security features of snmpv3 would make configuration using snmp more tenable. In reality, the complexity of snmpv3 security, and the continuation of snmp being listed as a top-ten vulnerability, discouraged people from moving to it quickly, and the other difficulties of snmp led to Netconf being started, and SNMP being identified a reasonable choice for monitoring, but not configuration. So the nat-mib was overtaken by events related to IETF management protocols. RFC4008 was treated as an individual submission after the NAT WG closed, and it was reviewed by the MIDCOM WG. The IESG questioned whether NAT-MIB should be an IETF standard, because the official IETF stance at the time of IESG review was "NATs are bad; use IPv6". See comments for RFC4008. So RFC4008 never had strong support from the IETF community. Other technologies for working with NATs, such as STUN and TURN and ICE, were already gaining traction by the time the nat-mib was approved. I think Jon Peterson was one of the transport ADs at the time, and working for a service provider that used NATs. I recall him saying when the mib module was approved that he was glad the MIB work was finally completed so the community could focus on USEFUL approaches to nats and stop dealing with the NAT-MIB module. So the NAT-MIB was overtaken by NAT-related events even before its approval. NATs have had so many varieties, the behave WG was created to try to get all the various NAT approaches to work together better. The configuration approach of the nat-mib only addressed a subset of available NATs. So the nat-mib never got much implementation support, and the behave WG checked and found few implementations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I wanted to check this condition in RFC4181: - On the other hand, the module name MUST NOT be changed (except to correct typographical errors), existing definitions (even obsolete ones) MUST NOT be removed from the MIB module, and descriptors and OBJECT IDENTIFIER values associated with existing definitions MUST NOT be changed or re-assigned. A word expressing that all RFC 4008 MIB objects are included in this version, but with only the STATUS changed to deprecated would be helpful. EDITORIAL * change the copyright date to 2015 * Unused Reference: 'RFC4787' is defined, but no reference was found in the text. * SNMP acronym is the first time used in Section 1 unexpaned. The acronym is expanded later in Section 2. Expand it already in Section 1. From nobody Mon Jun 15 08:23: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 6DD7A1A884B; Mon, 15 Jun 2015 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 lppAT0MOIOTl; Mon, 15 Jun 2015 08:22:58 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 0F4491A883D; Mon, 15 Jun 2015 08:22:58 -0700 (PDT) Received: by igbzc4 with SMTP id zc4so57071267igb.0; Mon, 15 Jun 2015 08:22:57 -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=bDQywCtYnGGyqVCIG9XkOI3IpeWGcwxG6fn9TlY3Exg=; b=m0XV2gcP6ChYI1afbOLvZh7SXSQ3iV+LlRBgUNHBHoRutVS/g/iALVak3PhIqOtyRQ HwZOo9pQl+okMTlzR6fYJAKjDGYOqH4i4pDiGZ5VcQ7P1BfTh/LPvW46A1uAg2bcx5Ta 41ew2zBQxc/pjJGnPuLW0R9sx/qHBZ1E3992xy39MKTd18pp++TB3/1RLbu/5ivu8O85 XJ3TtBdyC5XpGzyupI8qNQaf4Hj0IVDtBzRsAeTwcOIpoNbFm9dakhI/yVc9kbf0SmSf KT1m/9tJySzEbvsH9S5UPtF/emLlLth72WfpYB+gVx2UjPBXrzXaEBDZ6iWdZBSA6mo9 Jmzw== X-Received: by 10.50.43.227 with SMTP id z3mr21698351igl.22.1434381777536; Mon, 15 Jun 2015 08:22:57 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-32-206.tor.primus.ca. [173.206.32.206]) by mx.google.com with ESMTPSA id x4sm9033495iod.26.2015.06.15.08.22.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 08:22:56 -0700 (PDT) Message-ID: <557EEDCF.9000506@gmail.com> Date: Mon, 15 Jun 2015 11:22:55 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Benoit Claise , ietfdbh , 'The IESG' References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> In-Reply-To: <5575EA98.1080009@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sperreault@jive.ca, jouni.nospam@gmail.com, behave@ietf.org, 'Spencer Dawkins' , tina.tsou.zouting@huawei.com Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 15 Jun 2015 15:22:59 -0000 I'm cleaning up this document and responding to particular open points. The main change to the document itself is to add the following sentences to the Security Considerations section. I will also review Jouni's comments to make sure they are all covered. "Amongst other matters, these considerations cover the case where both this MIB module and NAT-MIB-V2 are present. In fact, such a situation is unlikely because , as a MIB module oriented toward configuration, was overtaken by events and saw little implementation." Tom On 08/06/2015 3:18 PM, Benoit Claise wrote: > Thanks Dave for the background information. ... >>> >>> - This point above is in line with Jouni's feedback. >>> * There is also no text about operational and management implications >>> related to deprecation process of the old MIB and migrating to the >>> new (to be approved) NAT-MIB-v2). [PTT] Covered in the v2 document. ... >>> >>> I started to file a DISCUSS on that very point. However, I was so >>> bothered by this difference that I actually compared the MIB modules >>> extracted from this draft and from RFC4008. >>> I see two occurences of this change: InetAddress (SIZE (4|16) versus >>> InetAddress >>> Why? >>> [PTT] To get rid of a SMILINT warning about potentially excessive number of sub-identifiers. ... >>> >>> A word expressing that all RFC 4008 MIB objects are included in this >>> version, but with only the STATUS changed to deprecated would be >>> helpful. >>> [PTT] Added in the Abstract. "All RFC 4008 MIB objects are included in this version unchanged with only the STATUS changed to deprecated, with a non-substantive exception. The exception was to retype internet addresses with a (SIZE (4|16) qualification to get rid of a SMILINT warning." ... From nobody Mon Jun 15 10:17:24 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 3B9AB1A9022 for ; Mon, 15 Jun 2015 10:17:22 -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] 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 TS11WZrqtXy5; Mon, 15 Jun 2015 10:17:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF11E1A905E; Mon, 15 Jun 2015 10:17:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , "Spencer Dawkins" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150615171719.29288.17259.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 10:17:19 -0700 Archived-At: Subject: [BEHAVE] New Version Notification - draft-perrault-behave-deprecate-nat-mib-v1-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:17:22 -0000 A new version (-03) has been submitted for draft-perrault-behave-deprecate-nat-mib-v1: https://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-03.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-03 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. IETF Secretariat. From nobody Sun Jun 21 23:51:38 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 7CCDB1B2D58; Sun, 21 Jun 2015 23:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 XHE7X7SfLo8S; Sun, 21 Jun 2015 23:51:28 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0700C1B2D57; Sun, 21 Jun 2015 23:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4168; q=dns/txt; s=iport; t=1434955888; x=1436165488; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=JwWk2qXgwyPAkHKPzHtszofXP74LEm0XuDqZAyIQOeQ=; b=WmowXv349L8d7GvO8CkrHgGtQ61H8V1k2IlpwcbuT4ZTRor4nZtOZ4w3 idzPwLQPzl8tVQwel8y/TXYHubpl94fzlKfx6oMlyBbZjIA7rekxHqMQ3 oPTHtyJrvXxG/n4rw4kSiylmmkwiKIMpMgklh6+y2POGbnJ8Lr3EjlDZL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOBAABsIdV/xbLJq1cg2S6OYYchXYCgXcBAQEBAQGBC4QjAQEEeAEQCwQdFgQLCQMCAQIBRQYBDAgBAYgrDcgXAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLRYUGB4QrAQSTfYtOgTqEDYJrj38mY4FZgT88gnkBAQE X-IronPort-AV: E=Sophos;i="5.13,658,1427760000"; d="scan'208,217";a="532129144" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 22 Jun 2015 06:51:24 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5M6pOsG005838; Mon, 22 Jun 2015 06:51:24 GMT To: Tom Taylor , ietfdbh , "'The IESG'" References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> From: Benoit Claise Message-ID: <5587B06C.1080507@cisco.com> Date: Mon, 22 Jun 2015 08:51:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <557EEDCF.9000506@gmail.com> Content-Type: multipart/alternative; boundary="------------070801040807090600020400" Archived-At: Cc: sperreault@jive.ca, jouni.nospam@gmail.com, behave@ietf.org, 'Spencer Dawkins' , tina.tsou.zouting@huawei.com Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 22 Jun 2015 06:51:30 -0000 This is a multi-part message in MIME format. --------------070801040807090600020400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Thanks Tom, ... >>>> >>>> - This point above is in line with Jouni's feedback. >>>> * There is also no text about operational and management implications >>>> related to deprecation process of the old MIB and migrating to the >>>> new (to be approved) NAT-MIB-v2). > > [PTT] Covered in the v2 document. Can you please let me know which text addresses my DISCUSS. https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02 Also, for the copyright and date, I was referring to the MIB description: DESCRIPTION "This MIB module defines the generic managed objects for NAT. Copyright (C) The Internet Society (2014). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." Regards, Benoit > > ... >>>> >>>> I started to file a DISCUSS on that very point. However, I was so >>>> bothered by this difference that I actually compared the MIB modules >>>> extracted from this draft and from RFC4008. >>>> I see two occurences of this change: InetAddress (SIZE (4|16) versus >>>> InetAddress >>>> Why? --------------070801040807090600020400 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks Tom,
...

- This point above is in line with Jouni's feedback.
* There is also no text about operational and management implications
   related to deprecation process of the old MIB and migrating to the
   new (to be approved) NAT-MIB-v2).

[PTT] Covered in the v2 document.
Can you please let me know which text addresses my DISCUSS.
https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02

Also, for the copyright and date, I was referring to the MIB description:
        DESCRIPTION
                "This MIB module defines the generic managed objects
                 for NAT.

                 Copyright (C) The Internet Society (2014).  This
                 version of this MIB module is part of RFC yyyy; see
                 the RFC itself for full legal notices."

Regards, Benoit

...

I started to file a DISCUSS on that very point. However, I was so
bothered by this difference that I actually compared the MIB modules
extracted from this draft and from RFC4008.
I see two occurences of this change: InetAddress (SIZE (4|16) versus
InetAddress
Why?

--------------070801040807090600020400-- From nobody Mon Jun 22 09:39:58 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 5F1361ACE89; Mon, 22 Jun 2015 09:39:53 -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 hZuc06JgOEp1; Mon, 22 Jun 2015 09:39:51 -0700 (PDT) Received: from mail-vn0-x22c.google.com (mail-vn0-x22c.google.com [IPv6:2607:f8b0:400c:c0f::22c]) (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 A6C5D1ACD87; Mon, 22 Jun 2015 09:39:51 -0700 (PDT) Received: by vnbg129 with SMTP id g129so3242957vnb.9; Mon, 22 Jun 2015 09:39:51 -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=r1oGChMD0awjtFyQVrzZRNitZp8hIcAd/QkJ3Zemr/o=; b=Gpw0JPfH7s1XNPlcZEyJ8cLbznwCuqaG+OCFaP0ICYb/cONIBEhmAsw9FFY4ZX6n8Z aB0YlVjWa0qoG6PIwr5AzuVj0cDR7tNNIEiZexiHVWbXNAN6X7AnspaZjBQmrObMQL60 acK0ID61SueXtfIhy2GG/3O5m3vY60Be5pFw/jxxgvdVrhND01VdagmYkXZujddCA2h4 78P/c0wY7zAt3Ia3ZMtuPLL1Jz1aacyfpkpDcm2vZfxLAXQbQ8dSp4mIbTUsooyETPN4 bVFXk6gX1HoBQ3EpTxNbw+R1yEaIHr39LkGZmRl+vzokxoUZdHS/nchRkJHQr78Dp2PX uciQ== MIME-Version: 1.0 X-Received: by 10.52.137.19 with SMTP id qe19mr25528096vdb.86.1434991190925; Mon, 22 Jun 2015 09:39:50 -0700 (PDT) Received: by 10.31.195.6 with HTTP; Mon, 22 Jun 2015 09:39:50 -0700 (PDT) In-Reply-To: <5587B06C.1080507@cisco.com> References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> Date: Mon, 22 Jun 2015 12:39:50 -0400 Message-ID: From: Spencer Dawkins at IETF To: Benoit Claise Content-Type: multipart/alternative; boundary=bcaec51a89bc30f31c05191dec4b Archived-At: Cc: "behave@ietf.org" , Tina Tsou , Jouni Korhonen , The IESG , Tom Taylor , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 22 Jun 2015 16:39:53 -0000 --bcaec51a89bc30f31c05191dec4b Content-Type: text/plain; charset=UTF-8 Hi, Tom, Just keeping up ... On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise wrote: > Thanks Tom, > ... > > > - This point above is in line with Jouni's feedback. > * There is also no text about operational and management implications > related to deprecation process of the old MIB and migrating to the > new (to be approved) NAT-MIB-v2). > > > [PTT] Covered in the v2 document. > > Can you please let me know which text addresses my DISCUSS. > > https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02 > > Also, for the copyright and date, I was referring to the MIB description: > > DESCRIPTION > "This MIB module defines the generic managed objects > for NAT. > > Copyright (C) The Internet Society (2014). This > version of this MIB module is part of RFC yyyy; see > the RFC itself for full legal notices." > > > Regards, Benoit > These are the remaining points for Benoit's Discuss on this document, is that correct? Thanks, Spencer > > I started to file a DISCUSS on that very point. However, I was so > bothered by this difference that I actually compared the MIB modules > extracted from this draft and from RFC4008. > I see two occurences of this change: InetAddress (SIZE (4|16) versus > InetAddress > Why? > > > --bcaec51a89bc30f31c05191dec4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Tom,

Just keeping up ...

On Mon, Jun 22, 2015 at 2:5= 1 AM, Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Thanks Tom,
...

- This point above is in line with Jouni's feedback.
* There is also no text about operational and management implications
=C2=A0=C2=A0 related to deprecation process of the old MIB and migrating to the
=C2=A0=C2=A0 new (to be approved) NAT-MIB-v2).

[PTT] Covered in the v2 document.
Can you please let me know which text addresses my DISCUSS.
https://www.ietf.org/rfcdiff?url2=3Ddr= aft-perrault-behave-deprecate-nat-mib-v1-02

Also, for the copyright and date, I was referring to the MIB description:
        DESCRIPTION
                "This MIB module defines the generic managed objects
                 for NAT.

                 Copyright (C) The Internet Society (2014).  This
                 version of this MIB module is part of RFC yyyy; see
                 the RFC itself for full legal notices."

Regards, Benoit

These are the rem= aining points for Benoit's Discuss on this document, is that correct?

Thanks,

Spencer
= =C2=A0

I started to file a DISCUSS on that very point. However, I was so
bothered by this difference that I actually compared the MIB modules
extracted from this draft and from RFC4008.
I see two occurences of this change: InetAddress (SIZE (4|16) versus
InetAddress
Why?


--bcaec51a89bc30f31c05191dec4b-- From nobody Tue Jun 23 13:34: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 B3E7B1B30A2; Tue, 23 Jun 2015 13:34: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 gABfp5YTr1Nz; Tue, 23 Jun 2015 13:34:46 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::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 D4D931B309C; Tue, 23 Jun 2015 13:34:45 -0700 (PDT) Received: by ieqy10 with SMTP id y10so20082437ieq.0; Tue, 23 Jun 2015 13:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=0pKLC83VisMP9SfyIJ0HtEgDwbuSjMyIUtUS8yQDmMM=; b=EJTxCMMANKcgBLb26TJkVNOwaJL4Sx+lHl4l5lewWz6dCdlN0EXXy19UQ+2/xp1+Pj +QPeV0YJ3KO15HpFHtwwXWedCdD0CnrlbkhnG0/uipqYA9fNvZEGCkQgLoeeYJQZ1xQN mig498kwDCfYi/JD9C5/hezOJpaPLQv4uuPQiqeRtBd1ZQv+ZOGNfUM5eJs6R4OF4/sd yGDjtUoAttB2ixbJERd5KVe7hQ8JfHCiJm2+pjufZuYVZeO4xLZxgDigXPT8kpL5Rlrp E0Wlu4g04V3Vxq5e+uV0DIC+WyXbY0K8xLAj2WHdMV4pplklnqkRE0wZpBswFRyZM3XR qPWw== X-Received: by 10.43.151.83 with SMTP id kr19mr33659261icc.3.1435091685338; Tue, 23 Jun 2015 13:34:45 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-6-50.tor.primus.ca. [173.206.6.50]) by mx.google.com with ESMTPSA id g12sm15813447ioe.28.2015.06.23.13.34.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2015 13:34:44 -0700 (PDT) To: Spencer Dawkins at IETF , Benoit Claise References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> From: Tom Taylor Message-ID: <5589C2E3.7050002@gmail.com> Date: Tue, 23 Jun 2015 16:34:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "behave@ietf.org" , Tina Tsou , Jouni Korhonen , The IESG , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 23 Jun 2015 20:34:47 -0000 Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, it can be fixed in AUTH48. Reviewing the IESG evaluation, I note the suggestion to leave out the MIB module definition itself and just have text saying (as Joel suggested) that all objects are deprecated. Would people agree to that? That would eliminate my fiddling with syntax to eliminate SMILINT warnings. Regarding the Discuss: the Security Considerations section currently reads: "All objects in this MIB module have been deprecated. As a result, security considerations in [I-D.ietf-behave-nat-mib-v2] apply instead. Amongst other matters, these considerations cover the case where both this MIB module and NAT-MIB-V2 are present. In fact, such a situation is unlikely because [RFC4008], as a MIB module oriented toward configuration, was overtaken by events and saw little implementation." Was this too condensed? Tom On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote: > Hi, Tom, > > Just keeping up ... > > On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise wrote: > >> Thanks Tom, >> ... >> >> >> - This point above is in line with Jouni's feedback. >> * There is also no text about operational and management implications >> related to deprecation process of the old MIB and migrating to the >> new (to be approved) NAT-MIB-v2). >> >> >> [PTT] Covered in the v2 document. >> >> Can you please let me know which text addresses my DISCUSS. >> >> https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02 >> >> Also, for the copyright and date, I was referring to the MIB description: >> >> DESCRIPTION >> "This MIB module defines the generic managed objects >> for NAT. >> >> Copyright (C) The Internet Society (2014). This >> version of this MIB module is part of RFC yyyy; see >> the RFC itself for full legal notices." >> >> >> Regards, Benoit >> > > These are the remaining points for Benoit's Discuss on this document, is > that correct? > > Thanks, > > Spencer > > >> >> I started to file a DISCUSS on that very point. However, I was so >> bothered by this difference that I actually compared the MIB modules >> extracted from this draft and from RFC4008. >> I see two occurences of this change: InetAddress (SIZE (4|16) versus >> InetAddress >> Why? >> >> >> > From nobody Wed Jun 24 01:51:13 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 66C2B1A9075; Wed, 24 Jun 2015 01:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 YrPVX8alX0dM; Wed, 24 Jun 2015 01:51:11 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CE71B323C; Wed, 24 Jun 2015 01:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2764; q=dns/txt; s=iport; t=1435135861; x=1436345461; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/0bpKs10vokeosjrGBexa3bQJGS5l4h/J4TgLLNp7hI=; b=mRJLXBcpGdlBwi3ePQLnb4QL8sn9Qv743RWJBAZ9DLQMKRb8qHcwBxu0 En5Uy8YBGCfpZsYHKdVwjLEishUhWXlG6erofdJhMqyk2A1xHHjS0ipRD wRj4rg5WprvEOSnnjtByywemgVb5Jso9RQm/mJJiX0pNSdgS9RIgHbX7/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BwAwDMbopV/xbLJq1bg2Rfgx61XYQrCYFohXYCggIUAQEBAQEBAYEKhCIBAQEDASMVQAEQCxgCAgUWBAcCAgkDAgECAUUGAQwGAgEBiCMIDbZFllABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhiimFBgeCaIFDAQSTf4tRgTqEEIJrkAAmY4FagT88MYJIAQEB X-IronPort-AV: E=Sophos;i="5.13,671,1427760000"; d="scan'208";a="559988185" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 24 Jun 2015 08:50:59 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5O8owO4000326; Wed, 24 Jun 2015 08:50:58 GMT To: Tom Taylor , Spencer Dawkins at IETF References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> From: Benoit Claise Message-ID: <558A6F72.3060203@cisco.com> Date: Wed, 24 Jun 2015 10:50:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <5589C2E3.7050002@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "behave@ietf.org" , Tina Tsou , Jouni Korhonen , The IESG , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 08:51:12 -0000 Hi Tom, > Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, > it can be fixed in AUTH48. > > Reviewing the IESG evaluation, I note the suggestion to leave out the > MIB module definition itself and just have text saying (as Joel > suggested) that all objects are deprecated. Would people agree to > that? That would eliminate my fiddling with syntax to eliminate > SMILINT warnings. > > Regarding the Discuss: the Security Considerations section currently > reads: > > "All objects in this MIB module have been deprecated. As a result, > security considerations in [I-D.ietf-behave-nat-mib-v2] apply > instead. Amongst other matters, these considerations cover the case > where both this MIB module and NAT-MIB-V2 are present. In fact, such > a situation is unlikely because [RFC4008], as a MIB module oriented > toward configuration, was overtaken by events and saw little > implementation." > > Was this too condensed? Not what I was expecting, but I guess it does the job to clear the DISCUSS. Clearing now. Regards, Benoit > > > Tom > > On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote: >> Hi, Tom, >> >> Just keeping up ... >> >> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise >> wrote: >> >>> Thanks Tom, >>> ... >>> >>> >>> - This point above is in line with Jouni's feedback. >>> * There is also no text about operational and management implications >>> related to deprecation process of the old MIB and migrating to the >>> new (to be approved) NAT-MIB-v2). >>> >>> >>> [PTT] Covered in the v2 document. >>> >>> Can you please let me know which text addresses my DISCUSS. >>> >>> https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02 >>> >>> >>> Also, for the copyright and date, I was referring to the MIB >>> description: >>> >>> DESCRIPTION >>> "This MIB module defines the generic managed objects >>> for NAT. >>> >>> Copyright (C) The Internet Society (2014). This >>> version of this MIB module is part of RFC yyyy; see >>> the RFC itself for full legal notices." >>> >>> >>> Regards, Benoit >>> >> >> These are the remaining points for Benoit's Discuss on this document, is >> that correct? >> >> Thanks, >> >> Spencer >> >> >>> >>> I started to file a DISCUSS on that very point. However, I was so >>> bothered by this difference that I actually compared the MIB modules >>> extracted from this draft and from RFC4008. >>> I see two occurences of this change: InetAddress (SIZE (4|16) versus >>> InetAddress >>> Why? >>> >>> >>> >> > . > From nobody Wed Jun 24 03:26:27 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 3E31A1A020D; Wed, 24 Jun 2015 03:26:25 -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 50-qcb9FU4ry; Wed, 24 Jun 2015 03:26:22 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (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 9517E1A020B; Wed, 24 Jun 2015 03:26:22 -0700 (PDT) Received: by vnbf62 with SMTP id f62so5646047vnb.5; Wed, 24 Jun 2015 03:26:21 -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=ZiRQ74NOyAY3d/7cq7fHanfBWRdNtPj5N0TTnMYL/Eo=; b=R7NDPN2ASnJg7RPK/j54oqFgZgpPDDwM8TolCoVjEkgWRX+LzwfLReW+8DsVgh7HiO shdDhnwWTu82Tk2VAJUFeuKScf01EaW6iS2UVSnH7HQfm3gKHG+JEBnCNcKh7RL0sT3t IobFCxaOXG5QAVaHNVxXBXP6VrGdG/8ZtpzslF0vRb6cp9P5X27yavKxU5j409Eb54CR LA49eHHm0v8GESY5wbOSf8p27jrSBx4MM4bsxzc5uUEYla8x5QTSkDKRAZOC40IOawh0 LYoM1YWisviZV0jZy5q8qZ2dOVDsEIgtYT2NBiTRJn4cuHjagcjeI8cUTrG3QsVcr9zH TFFQ== MIME-Version: 1.0 X-Received: by 10.52.114.230 with SMTP id jj6mr23249154vdb.66.1435141581769; Wed, 24 Jun 2015 03:26:21 -0700 (PDT) Received: by 10.31.195.6 with HTTP; Wed, 24 Jun 2015 03:26:21 -0700 (PDT) Received: by 10.31.195.6 with HTTP; Wed, 24 Jun 2015 03:26:21 -0700 (PDT) In-Reply-To: <558A6F72.3060203@cisco.com> References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> Date: Wed, 24 Jun 2015 06:26:21 -0400 Message-ID: From: Spencer Dawkins at IETF To: Benoit Claise Content-Type: multipart/alternative; boundary=bcaec5489e452f1144051940f031 Archived-At: Cc: behave@ietf.org, Tina Tsou , Jouni Korhonen , The IESG , Tom Taylor , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 10:26:25 -0000 --bcaec5489e452f1144051940f031 Content-Type: text/plain; charset=UTF-8 On Jun 24, 2015 04:51, "Benoit Claise" wrote: > > Hi Tom, > >> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, it can be fixed in AUTH48. >> >> Reviewing the IESG evaluation, I note the suggestion to leave out the MIB module definition itself and just have text saying (as Joel suggested) that all objects are deprecated. Would people agree to that? That would eliminate my fiddling with syntax to eliminate SMILINT warnings. So, two questions - - is the issue that changing the definition while deprecating the objects is strange? - if the document just said "all objects are deprecated", would the resulting MIB modules still produce SMILINT warnings? Obviously, I'm wondering if the right answer is to leave the syntax unchanged, and point out that the syntax generates SMILINT warnings whether the objects are deprecated or not, but since all this document is doing is deprecating objects, the syntax is left unchanged, and anyone who implements the V1 MIB now will have bigger problems than the SMILINT warnings, but I don't know that's the right answer. >> Regarding the Discuss: the Security Considerations section currently reads: >> >> "All objects in this MIB module have been deprecated. As a result, >> security considerations in [I-D.ietf-behave-nat-mib-v2] apply >> instead. Amongst other matters, these considerations cover the case >> where both this MIB module and NAT-MIB-V2 are present. In fact, such >> a situation is unlikely because [RFC4008], as a MIB module oriented >> toward configuration, was overtaken by events and saw little >> implementation." >> >> Was this too condensed? > > Not what I was expecting, but I guess it does the job to clear the DISCUSS. Clearing now. Thank you, of course. Spencer > Regards, Benoit > > >> >> >> Tom >> >> On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote: >>> >>> Hi, Tom, >>> >>> Just keeping up ... >>> >>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise wrote: >>> >>>> Thanks Tom, >>>> ... >>>> >>>> >>>> - This point above is in line with Jouni's feedback. >>>> * There is also no text about operational and management implications >>>> related to deprecation process of the old MIB and migrating to the >>>> new (to be approved) NAT-MIB-v2). >>>> >>>> >>>> [PTT] Covered in the v2 document. >>>> >>>> Can you please let me know which text addresses my DISCUSS. >>>> >>>> https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02 >>>> >>>> Also, for the copyright and date, I was referring to the MIB description: >>>> >>>> DESCRIPTION >>>> "This MIB module defines the generic managed objects >>>> for NAT. >>>> >>>> Copyright (C) The Internet Society (2014). This >>>> version of this MIB module is part of RFC yyyy; see >>>> the RFC itself for full legal notices." >>>> >>>> >>>> Regards, Benoit >>>> >>> >>> These are the remaining points for Benoit's Discuss on this document, is >>> that correct? >>> >>> Thanks, >>> >>> Spencer >>> >>> >>>> >>>> I started to file a DISCUSS on that very point. However, I was so >>>> bothered by this difference that I actually compared the MIB modules >>>> extracted from this draft and from RFC4008. >>>> I see two occurences of this change: InetAddress (SIZE (4|16) versus >>>> InetAddress >>>> Why? >>>> >>>> >>>> >>> >> . >> > --bcaec5489e452f1144051940f031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 24, 2015 04:51, "Benoit Claise" <bclaise@cisco.com> wrote:
>
> Hi Tom,
>
>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyrigh= t thing, it can be fixed in AUTH48.
>>
>> Reviewing the IESG evaluation, I note the suggestion to leave out = the MIB module definition itself and just have text saying (as Joel suggest= ed) that all objects are deprecated. Would people agree to that? That would= eliminate my fiddling with syntax to eliminate SMILINT warnings.

So, two questions -

- is the issue that changing the definition while deprecatin= g the objects is strange?

- if the document just said "all objects are deprecated= ", would the resulting MIB modules still produce SMILINT warnings?

Obviously, I'm wondering if the right answer is to leave= the syntax unchanged, and point out that the syntax generates SMILINT warn= ings whether the objects are deprecated or not, but since all this document= is doing is deprecating objects, the syntax is left unchanged, and anyone = who implements the V1 MIB now will have bigger problems than the SMILINT wa= rnings, but I don't know that's the right answer.

>> Regarding the Discuss: the Security Considerations = section currently reads:
>>
>> =C2=A0 "All objects in this MIB module have been deprecated.= =C2=A0 As a result,
>> =C2=A0 =C2=A0security considerations in [I-D.ietf-behave-nat-mib-v= 2] apply
>> =C2=A0 =C2=A0instead.=C2=A0 Amongst other matters, these considera= tions cover the case
>> =C2=A0 =C2=A0where both this MIB module and NAT-MIB-V2 are present= .=C2=A0 In fact, such
>> =C2=A0 =C2=A0a situation is unlikely because [RFC4008], as a MIB m= odule oriented
>> =C2=A0 =C2=A0toward configuration, was overtaken by events and saw= little
>> =C2=A0 =C2=A0implementation."
>>
>> Was this too condensed?
>
> Not what I was expecting, but I guess it does the job to clear the DIS= CUSS. Clearing now.

Thank you, of course.

Spencer

> Regards, Benoit
>
>
>>
>>
>> Tom
>>
>> On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote:
>>>
>>> Hi, Tom,
>>>
>>> Just keeping up ...
>>>
>>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise <bclaise@cisco.com> wrote:
>>>
>>>> =C2=A0 Thanks Tom,
>>>> ...
>>>>
>>>>
>>>> - This point above is in line with Jouni's feedback. >>>> * There is also no text about operational and management i= mplications
>>>> =C2=A0 =C2=A0 related to deprecation process of the old MI= B and migrating to the
>>>> =C2=A0 =C2=A0 new (to be approved) NAT-MIB-v2).
>>>>
>>>>
>>>> [PTT] Covered in the v2 document.
>>>>
>>>> Can you please let me know which text addresses my DISCUSS= .
>>>>
>>>> https://www.ietf.org/rfcdiff?url2=3Ddra= ft-perrault-behave-deprecate-nat-mib-v1-02
>>>>
>>>> Also, for the copyright and date, I was referring to the M= IB description:
>>>>
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DESCRIPTION
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"This MIB module defines the generic managed objects
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 for NAT.
>>>>
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Copyright (C) The Internet Society (2014). This
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 version of this MIB module is part of RFC yyyy; see
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 the RFC itself for full legal notices."
>>>>
>>>>
>>>> Regards, Benoit
>>>>
>>>
>>> These are the remaining points for Benoit's Discuss on thi= s document, is
>>> that correct?
>>>
>>> Thanks,
>>>
>>> Spencer
>>>
>>>
>>>>
>>>> I started to file a DISCUSS on that very point. However, I= was so
>>>> bothered by this difference that I actually compared the M= IB modules
>>>> extracted from this draft and from RFC4008.
>>>> I see two occurences of this change: InetAddress (SIZE (4|= 16) versus
>>>> InetAddress
>>>> Why?
>>>>
>>>>
>>>>
>>>
>> .
>>
>

--bcaec5489e452f1144051940f031-- From nobody Wed Jun 24 05:10:31 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 D2AA01A89B4; Wed, 24 Jun 2015 05:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 pyGNMDlS4zjC; Wed, 24 Jun 2015 05:10:27 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F9F1A0130; Wed, 24 Jun 2015 05:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11850; q=dns/txt; s=iport; t=1435147827; x=1436357427; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=nTkz2Mf2cYi/JfIwgUT0sUIuJVDz6EgS/IoVL4tNP74=; b=QKuv/8u53mngBv7bsBIX8IaB62EBgsXOvtfEO36b3zgpijlgL3LKat85 aiXJ9ZVQmku1IRDL+Lzv3yqfJO4RMZqWfUeb5MVe2dVarFAPQ0vfIQtXE qhzuJd4uqMME5wNefJx36Wh/kq0Y5I9nPQJK9KtzrS93qqNVd4QvCZqNH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIAwDInIpV/xbLJq1bg2Vfgx61QIQrCYFohXYCggUUAQEBAQEBAYEKhCIBAQEDASNVAQULCQIYCRYEBAMCAgkDAgECATQRBg0GAgEBiCMIDZlEnRmWUgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0qFBgeCaIFDAQSUBYtRgTqEEIJrkAMmY4EpHBWBPzwxgkgBAQE X-IronPort-AV: E=Sophos;i="5.13,671,1427760000"; d="scan'208,217";a="542091896" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 24 Jun 2015 12:10:24 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t5OCAN12029383; Wed, 24 Jun 2015 12:10:23 GMT To: Spencer Dawkins at IETF References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> From: Benoit Claise Message-ID: <558A9E2F.6050506@cisco.com> Date: Wed, 24 Jun 2015 14:10:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030006050909090307030704" Archived-At: Cc: behave@ietf.org, Tina Tsou , Jouni Korhonen , The IESG , Tom Taylor , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 12:10:30 -0000 This is a multi-part message in MIME format. --------------030006050909090307030704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, > > > On Jun 24, 2015 04:51, "Benoit Claise" > wrote: > > > > Hi Tom, > > > >> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright > thing, it can be fixed in AUTH48. > >> > >> Reviewing the IESG evaluation, I note the suggestion to leave out > the MIB module definition itself and just have text saying (as Joel > suggested) that all objects are deprecated. Would people agree to > that? That would eliminate my fiddling with syntax to eliminate > SMILINT warnings. > Forgot to reply to this one. I believe the draft makes sense as done right now. People might want to extract all MIB modules from RFC and load them all. This way, they would directly see in their MIB browser that the MIB objects are deprecated. Regards, Benoit > > So, two questions - > > - is the issue that changing the definition while deprecating the > objects is strange? > > - if the document just said "all objects are deprecated", would the > resulting MIB modules still produce SMILINT warnings? > > Obviously, I'm wondering if the right answer is to leave the syntax > unchanged, and point out that the syntax generates SMILINT warnings > whether the objects are deprecated or not, but since all this document > is doing is deprecating objects, the syntax is left unchanged, and > anyone who implements the V1 MIB now will have bigger problems than > the SMILINT warnings, but I don't know that's the right answer. > > >> Regarding the Discuss: the Security Considerations section > currently reads: > >> > >> "All objects in this MIB module have been deprecated. As a result, > >> security considerations in [I-D.ietf-behave-nat-mib-v2] apply > >> instead. Amongst other matters, these considerations cover the case > >> where both this MIB module and NAT-MIB-V2 are present. In fact, > such > >> a situation is unlikely because [RFC4008], as a MIB module oriented > >> toward configuration, was overtaken by events and saw little > >> implementation." > >> > >> Was this too condensed? > > > > Not what I was expecting, but I guess it does the job to clear the > DISCUSS. Clearing now. > > Thank you, of course. > > Spencer > > > Regards, Benoit > > > > > >> > >> > >> Tom > >> > >> On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote: > >>> > >>> Hi, Tom, > >>> > >>> Just keeping up ... > >>> > >>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise > wrote: > >>> > >>>> Thanks Tom, > >>>> ... > >>>> > >>>> > >>>> - This point above is in line with Jouni's feedback. > >>>> * There is also no text about operational and management implications > >>>> related to deprecation process of the old MIB and migrating > to the > >>>> new (to be approved) NAT-MIB-v2). > >>>> > >>>> > >>>> [PTT] Covered in the v2 document. > >>>> > >>>> Can you please let me know which text addresses my DISCUSS. > >>>> > >>>> > https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02 > > >>>> > >>>> Also, for the copyright and date, I was referring to the MIB > description: > >>>> > >>>> DESCRIPTION > >>>> "This MIB module defines the generic managed objects > >>>> for NAT. > >>>> > >>>> Copyright (C) The Internet Society (2014). This > >>>> version of this MIB module is part of RFC yyyy; see > >>>> the RFC itself for full legal notices." > >>>> > >>>> > >>>> Regards, Benoit > >>>> > >>> > >>> These are the remaining points for Benoit's Discuss on this > document, is > >>> that correct? > >>> > >>> Thanks, > >>> > >>> Spencer > >>> > >>> > >>>> > >>>> I started to file a DISCUSS on that very point. However, I was so > >>>> bothered by this difference that I actually compared the MIB modules > >>>> extracted from this draft and from RFC4008. > >>>> I see two occurences of this change: InetAddress (SIZE (4|16) versus > >>>> InetAddress > >>>> Why? > >>>> > >>>> > >>>> > >>> > >> . > >> > > > --------------030006050909090307030704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,


On Jun 24, 2015 04:51, "Benoit Claise" <bclaise@cisco.com> wrote:
>
> Hi Tom,
>
>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, it can be fixed in AUTH48.
>>
>> Reviewing the IESG evaluation, I note the suggestion to leave out the MIB module definition itself and just have text saying (as Joel suggested) that all objects are deprecated. Would people agree to that? That would eliminate my fiddling with syntax to eliminate SMILINT warnings.

Forgot to reply to this one.
I believe the draft makes sense as done right now.
People might want to extract all MIB modules from RFC and load them all.
This way, they would directly see in their MIB browser that the MIB objects are deprecated.

Regards, Benoit

So, two questions -

- is the issue that changing the definition while deprecating the objects is strange?

- if the document just said "all objects are deprecated", would the resulting MIB modules still produce SMILINT warnings?

Obviously, I'm wondering if the right answer is to leave the syntax unchanged, and point out that the syntax generates SMILINT warnings whether the objects are deprecated or not, but since all this document is doing is deprecating objects, the syntax is left unchanged, and anyone who implements the V1 MIB now will have bigger problems than the SMILINT warnings, but I don't know that's the right answer.

>> Regarding the Discuss: the Security Considerations section currently reads:
>>
>>   "All objects in this MIB module have been deprecated.  As a result,
>>    security considerations in [I-D.ietf-behave-nat-mib-v2] apply
>>    instead.  Amongst other matters, these considerations cover the case
>>    where both this MIB module and NAT-MIB-V2 are present.  In fact, such
>>    a situation is unlikely because [RFC4008], as a MIB module oriented
>>    toward configuration, was overtaken by events and saw little
>>    implementation."
>>
>> Was this too condensed?
>
> Not what I was expecting, but I guess it does the job to clear the DISCUSS. Clearing now.

Thank you, of course.

Spencer

> Regards, Benoit
>
>
>>
>>
>> Tom
>>
>> On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote:
>>>
>>> Hi, Tom,
>>>
>>> Just keeping up ...
>>>
>>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise <bclaise@cisco.com> wrote:
>>>
>>>>   Thanks Tom,
>>>> ...
>>>>
>>>>
>>>> - This point above is in line with Jouni's feedback.
>>>> * There is also no text about operational and management implications
>>>>     related to deprecation process of the old MIB and migrating to the
>>>>     new (to be approved) NAT-MIB-v2).
>>>>
>>>>
>>>> [PTT] Covered in the v2 document.
>>>>
>>>> Can you please let me know which text addresses my DISCUSS.
>>>>
>>>> https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02
>>>>
>>>> Also, for the copyright and date, I was referring to the MIB description:
>>>>
>>>>          DESCRIPTION
>>>>                  "This MIB module defines the generic managed objects
>>>>                   for NAT.
>>>>
>>>>                   Copyright (C) The Internet Society (2014). This
>>>>                   version of this MIB module is part of RFC yyyy; see
>>>>                   the RFC itself for full legal notices."
>>>>
>>>>
>>>> Regards, Benoit
>>>>
>>>
>>> These are the remaining points for Benoit's Discuss on this document, is
>>> that correct?
>>>
>>> Thanks,
>>>
>>> Spencer
>>>
>>>
>>>>
>>>> I started to file a DISCUSS on that very point. However, I was so
>>>> bothered by this difference that I actually compared the MIB modules
>>>> extracted from this draft and from RFC4008.
>>>> I see two occurences of this change: InetAddress (SIZE (4|16) versus
>>>> InetAddress
>>>> Why?
>>>>
>>>>
>>>>
>>>
>> .
>>
>


--------------030006050909090307030704-- From nobody Wed Jun 24 08:17:04 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 2AED31A8A7F; Wed, 24 Jun 2015 08:17: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 W6MarR0t4lz0; Wed, 24 Jun 2015 08:17:01 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::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 309ED1A8A72; Wed, 24 Jun 2015 08:17:01 -0700 (PDT) Received: by iebrt9 with SMTP id rt9so35350441ieb.2; Wed, 24 Jun 2015 08:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=N76fYyW//1TfK/0QRwdbXGGV9bPDOJWX/FsL+fu5qz0=; b=ZB0kBwo799Glz8ovC07J7vsY8FSvyoN41wPAIdOa3nLiUsNIsoK5MxXXkZaFmfZqQ8 u7TZYDhqqgXaHUQSs7R9InNajxwN6rj/+BQIbdoNLejHFCe3cGR2m1EWZ0V7CdyVhWvm h1QCMeRluHnnbvIFdxZWDyN+wBpY6kTnoUASylZCyzI5s4BX/xjDYJZbE3m7IIC/j46O kNGnSxro1R+gqN/KTNcGl7LOSIuLHPArb8comR03hZ07Gr5AyHqmlfepolN9gdHCnqGu H8zQLq9hhe8H1q7Jeq32ifTJcPUXiY2k3sJhJI+Gr/lDVdbr+qmY7iZ6g591oL2NMawr j4SA== X-Received: by 10.107.138.87 with SMTP id m84mr52616315iod.80.1435159020735; Wed, 24 Jun 2015 08:17:00 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-6-50.tor.primus.ca. [173.206.6.50]) by mx.google.com with ESMTPSA id o9sm17483297ioe.35.2015.06.24.08.16.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 08:17:00 -0700 (PDT) To: Spencer Dawkins at IETF , Benoit Claise References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> From: Tom Taylor Message-ID: <558AC9EA.6070907@gmail.com> Date: Wed, 24 Jun 2015 11:16:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: behave@ietf.org, Tina Tsou , Jouni Korhonen , The IESG , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 15:17:03 -0000 Below with [PTT] On 24/06/2015 6:26 AM, Spencer Dawkins at IETF wrote: > On Jun 24, 2015 04:51, "Benoit Claise" wrote: >> >> Hi Tom, >> >>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, > it can be fixed in AUTH48. >>> >>> Reviewing the IESG evaluation, I note the suggestion to leave out the > MIB module definition itself and just have text saying (as Joel suggested) > that all objects are deprecated. Would people agree to that? That would > eliminate my fiddling with syntax to eliminate SMILINT warnings. > > So, two questions - > > - is the issue that changing the definition while deprecating the objects > is strange? [PTT] Yes, per guidelines quoted by Benoit. > > - if the document just said "all objects are deprecated", would the > resulting MIB modules still produce SMILINT warnings? [PTT] Yes. I just verified that RFC 4008 generates the following warnings mibs/NAT-MIB:932: [5] {index-exceeds-too-large} warning: index of row `natAddrBindEntry' can exceed OID size limit by 141 subidentifier(s) mibs/NAT-MIB:1162: [5] {index-exceeds-too-large} warning: index of row `natAddrPortBindEntry' can exceed OID size limit by 143 subidentifier(s) > > Obviously, I'm wondering if the right answer is to leave the syntax > unchanged, and point out that the syntax generates SMILINT warnings whether > the objects are deprecated or not, but since all this document is doing is > deprecating objects, the syntax is left unchanged, and anyone who > implements the V1 MIB now will have bigger problems than the SMILINT > warnings, but I don't know that's the right answer. > ... From nobody Wed Jun 24 08:19: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 E80CD1A8AA5; Wed, 24 Jun 2015 08:18:58 -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 Md0_nWP_adLr; Wed, 24 Jun 2015 08:18:57 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 618BD1A8A91; Wed, 24 Jun 2015 08:18:57 -0700 (PDT) Received: by igblr2 with SMTP id lr2so77685569igb.0; Wed, 24 Jun 2015 08:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=XaW8sDotSyBlMmb2aLzfUpJJRLRpqhd/9nRuMAyJRTA=; b=fl6LbSa0HnXr5Vu1C2TAaSvHSAC/PG8gMfiocQsNYsVBC2GI61lCCDdoMCT+YOPghl zhzZcUwwJVrkC2yrb4vLOY8MXAKxyhTRrMK62K7wEMoXojgMkmJH5v0wi+A8HxXO5IjL CaV7hwvLwedkj7TYSnnehCbyklpTL7kxBMvzaH8LuySom5OUT7rxHATmz9AnRBV2hoyr E/IC4t6BNByHtGe5Z4v397QWXThUkm3UHF9enaX3DIthMQ3RpHwORRx7QL59sbSd0M/0 ZiLEATYeiBzCfZW3I7usYMY3BtPDa1NBXG8FIppzLLZtkuCHeFKsgwPl744wOkXSuyMn GzwA== X-Received: by 10.50.143.104 with SMTP id sd8mr3831523igb.14.1435159136855; Wed, 24 Jun 2015 08:18:56 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-6-50.tor.primus.ca. [173.206.6.50]) by mx.google.com with ESMTPSA id k74sm17493024iok.30.2015.06.24.08.18.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 08:18:56 -0700 (PDT) To: Benoit Claise , Spencer Dawkins at IETF References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> <558A9E2F.6050506@cisco.com> From: Tom Taylor Message-ID: <558ACA5F.7000105@gmail.com> Date: Wed, 24 Jun 2015 11:18:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <558A9E2F.6050506@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: behave@ietf.org, Tina Tsou , Jouni Korhonen , The IESG , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 15:18:59 -0000 OK, our messages crossed. I will take no further actions other than making sure the copyright date is fixed. Tom On 24/06/2015 8:10 AM, Benoit Claise wrote: > Dear all, >> >> >> On Jun 24, 2015 04:51, "Benoit Claise" > > wrote: >> > >> > Hi Tom, >> > >> >> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright >> thing, it can be fixed in AUTH48. >> >> >> >> Reviewing the IESG evaluation, I note the suggestion to leave out >> the MIB module definition itself and just have text saying (as Joel >> suggested) that all objects are deprecated. Would people agree to >> that? That would eliminate my fiddling with syntax to eliminate >> SMILINT warnings. >> > Forgot to reply to this one. > I believe the draft makes sense as done right now. > People might want to extract all MIB modules from RFC and load them all. > This way, they would directly see in their MIB browser that the MIB > objects are deprecated. > > Regards, Benoit >> >> So, two questions - >> >> - is the issue that changing the definition while deprecating the >> objects is strange? >> >> - if the document just said "all objects are deprecated", would the >> resulting MIB modules still produce SMILINT warnings? >> >> Obviously, I'm wondering if the right answer is to leave the syntax >> unchanged, and point out that the syntax generates SMILINT warnings >> whether the objects are deprecated or not, but since all this document >> is doing is deprecating objects, the syntax is left unchanged, and >> anyone who implements the V1 MIB now will have bigger problems than >> the SMILINT warnings, but I don't know that's the right answer. >> ... From nobody Wed Jun 24 08:21:30 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 1E4421A8AF5; Wed, 24 Jun 2015 08:21:24 -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 LAtnqCO_aMyl; Wed, 24 Jun 2015 08:21:16 -0700 (PDT) Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com [IPv6:2607:f8b0:400c:c0f::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 79EC31A8ADA; Wed, 24 Jun 2015 08:21:11 -0700 (PDT) Received: by vnav203 with SMTP id v203so6789684vna.8; Wed, 24 Jun 2015 08:21:10 -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=DMolaIFaYXdGkrhw8VynerbVRZ+N9VGbsPeaUrwriDk=; b=KYSSOyTtvJt3VHO39g0i+AeZYnmxY5l4cNmc/GqDHuKFr51ZdN7rRQQL984jURTV2z OcVe4Ro/nTn/ZMZ1rLuZh2Lu243ethPdHv0xFY4AQ4Rjh73VEMg4meC9w08l0mp7qRUS xfYhq6u2uu/ctTINZihV4qpUdXkZ4AWfZtS9Tpb7SV0eX7dlX60N5/f3EWSOrXmXlPgR rR31yrvxagEtxvcmldc8kd1KzxJQUFQ/v6ccRpSSWzOFJpnz90QORn4stA5nF42OjfhV sovNil2mLbgUck3OUHlMy6iZUTc6T+oEuA8F4OJZ2WqrvGwhtTxPovH3wPk1Ve4Howzs lpPg== MIME-Version: 1.0 X-Received: by 10.52.122.52 with SMTP id lp20mr37118223vdb.64.1435159270491; Wed, 24 Jun 2015 08:21:10 -0700 (PDT) Received: by 10.31.195.6 with HTTP; Wed, 24 Jun 2015 08:21:10 -0700 (PDT) In-Reply-To: <558A9E2F.6050506@cisco.com> References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> <558A9E2F.6050506@cisco.com> Date: Wed, 24 Jun 2015 11:21:10 -0400 Message-ID: From: Spencer Dawkins at IETF To: Benoit Claise Content-Type: multipart/alternative; boundary=089e013a13bc838e670519450e03 Archived-At: Cc: "behave@ietf.org" , Tina Tsou , Jouni Korhonen , The IESG , Tom Taylor , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 15:21:24 -0000 --089e013a13bc838e670519450e03 Content-Type: text/plain; charset=UTF-8 So, I think we're finishing up here ... On Wed, Jun 24, 2015 at 8:10 AM, Benoit Claise wrote: > Dear all, > > > On Jun 24, 2015 04:51, "Benoit Claise" < > bclaise@cisco.com> wrote: > > > > Hi Tom, > > > >> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, > it can be fixed in AUTH48. > >> > >> Reviewing the IESG evaluation, I note the suggestion to leave out the > MIB module definition itself and just have text saying (as Joel suggested) > that all objects are deprecated. Would people agree to that? That would > eliminate my fiddling with syntax to eliminate SMILINT warnings. > > Forgot to reply to this one. > I believe the draft makes sense as done right now. > People might want to extract all MIB modules from RFC and load them all. > This way, they would directly see in their MIB browser that the MIB > objects are deprecated. > So, that makes sense to me. The related question was whether the syntax popping up SMILINT warnings was OK for someone who did that - as I understand it, the syntax in the objects being deprecated would generate the same warnings, without the changes Tom had proposed. Could you clue me in? Thanks! Spencer p.s. Tom, when Benoit answets this question, the only other point I'm aware of was 2014 copyright dates in the object definitions. I would be more comfortable sending the RFC Editor a draft version that they don't have to fix and we don't have to check in AUTH48. Could you spin a version with the copyright date fix, plus whatever you and Benoit converge on re: syntax? > Regards, Benoit > > So, two questions - > > - is the issue that changing the definition while deprecating the objects > is strange? > > - if the document just said "all objects are deprecated", would the > resulting MIB modules still produce SMILINT warnings? > > Obviously, I'm wondering if the right answer is to leave the syntax > unchanged, and point out that the syntax generates SMILINT warnings whether > the objects are deprecated or not, but since all this document is doing is > deprecating objects, the syntax is left unchanged, and anyone who > implements the V1 MIB now will have bigger problems than the SMILINT > warnings, but I don't know that's the right answer. > > >> Regarding the Discuss: the Security Considerations section currently > reads: > >> > >> "All objects in this MIB module have been deprecated. As a result, > >> security considerations in [I-D.ietf-behave-nat-mib-v2] apply > >> instead. Amongst other matters, these considerations cover the case > >> where both this MIB module and NAT-MIB-V2 are present. In fact, such > >> a situation is unlikely because [RFC4008], as a MIB module oriented > >> toward configuration, was overtaken by events and saw little > >> implementation." > >> > >> Was this too condensed? > > > > Not what I was expecting, but I guess it does the job to clear the > DISCUSS. Clearing now. > > Thank you, of course. > > Spencer > > > Regards, Benoit > > > > > >> > >> > >> Tom > >> > >> On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote: > >>> > >>> Hi, Tom, > >>> > >>> Just keeping up ... > >>> > >>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise < > bclaise@cisco.com> wrote: > >>> > >>>> Thanks Tom, > >>>> ... > >>>> > >>>> > >>>> - This point above is in line with Jouni's feedback. > >>>> * There is also no text about operational and management implications > >>>> related to deprecation process of the old MIB and migrating to the > >>>> new (to be approved) NAT-MIB-v2). > >>>> > >>>> > >>>> [PTT] Covered in the v2 document. > >>>> > >>>> Can you please let me know which text addresses my DISCUSS. > >>>> > >>>> > https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02 > >>>> > >>>> Also, for the copyright and date, I was referring to the MIB > description: > >>>> > >>>> DESCRIPTION > >>>> "This MIB module defines the generic managed objects > >>>> for NAT. > >>>> > >>>> Copyright (C) The Internet Society (2014). This > >>>> version of this MIB module is part of RFC yyyy; see > >>>> the RFC itself for full legal notices." > >>>> > >>>> > >>>> Regards, Benoit > >>>> > >>> > >>> These are the remaining points for Benoit's Discuss on this document, > is > >>> that correct? > >>> > >>> Thanks, > >>> > >>> Spencer > >>> > >>> > >>>> > >>>> I started to file a DISCUSS on that very point. However, I was so > >>>> bothered by this difference that I actually compared the MIB modules > >>>> extracted from this draft and from RFC4008. > >>>> I see two occurences of this change: InetAddress (SIZE (4|16) versus > >>>> InetAddress > >>>> Why? > >>>> > >>>> > >>>> > >>> > >> . > >> > > > > > --089e013a13bc838e670519450e03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, I think we're finishing up here ...

On Wed, Jun 24, 2015 at 8:10 AM,= Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Dear all,
=20


On Jun 24, 2015 04:51, "Benoit Claise" <bclaise@cisco.com> wrote:
>
> Hi Tom,
>
>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, it can be fixed in AUTH48.
>>
>> Reviewing the IESG evaluation, I note the suggestion to leave out the MIB module definition itself and just have text saying (as Joel suggested) that all objects are deprecated. Would people agree to that? That would eliminate my fiddling with syntax to eliminate SMILINT warnings.

 Forgot to reply to this one.
I believe the draft makes sense as done right now.
People might want to extract all MIB modules from RFC and load them all.
This way, they would directly see in their MIB browser that the MIB objects are deprecated.

So, that = makes sense to me.=C2=A0

The related question was = whether the syntax popping up SMILINT warnings was OK for someone who did t= hat - as I understand it, the syntax in the objects being deprecated would = generate the same warnings, without the changes Tom had proposed.=C2=A0

Could you clue me in?

Thanks= !

Spencer

p.s. Tom, when = Benoit answets this question, the only other point I'm aware of was 201= 4 copyright dates in the object definitions. I would be more comfortable se= nding the RFC Editor a draft version that they don't have to fix and we= don't have to check in AUTH48. Could you spin a version with the copyr= ight date fix, plus whatever you and Benoit converge on re: syntax?

=C2=A0
Regards, Benoit

So, two questions -

- is the issue that changing the definition while deprecating the objects is strange?

- if the document just said "all objects are deprecated", would the resulting MIB modules still produce SMILINT warnings?

Obviously, I'm wondering if the right answer is to leave the syntax unchanged, and point out that the syntax generates SMILINT warnings whether the objects are deprecated or not, but since all this document is doing is deprecating objects, the syntax is left unchanged, and anyone who implements the V1 MIB now will have bigger problems than the SMILINT warnings, but I don't know that's the right answer.

>> Regarding the Discuss: the Security Considerations section currently reads:
>>
>> =C2=A0 "All objects in this MIB module have been deprecated.=C2=A0 As a result,
>> =C2=A0 =C2=A0security considerations in [I-D.ietf-behave-nat-mib-v2] apply
>> =C2=A0 =C2=A0instead.=C2=A0 Amongst other matters, these considerations cover the case
>> =C2=A0 =C2=A0where both this MIB module and NAT-MIB-V2 are present.=C2=A0 In fact, such
>> =C2=A0 =C2=A0a situation is unlikely because [RFC4008], as= a MIB module oriented
>> =C2=A0 =C2=A0toward configuration, was overtaken by events= and saw little
>> =C2=A0 =C2=A0implementation."
>>
>> Was this too condensed?
>
> Not what I was expecting, but I guess it does the job to clear the DISCUSS. Clearing now.

Thank you, of course.

Spencer

> Regards, Benoit
>
>
>>
>>
>> Tom
>>
>> On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote:
>>>
>>> Hi, Tom,
>>>
>>> Just keeping up ...
>>>
>>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise <bclaise@cisco.com> wrote:
>>>
>>>> =C2=A0 Thanks Tom,
>>>> ...
>>>>
>>>>
>>>> - This point above is in line with Jouni's feedback.
>>>> * There is also no text about operational and management implications
>>>> =C2=A0 =C2=A0 related to deprecation process of th= e old MIB and migrating to the
>>>> =C2=A0 =C2=A0 new (to be approved) NAT-MIB-v2). >>>>
>>>>
>>>> [PTT] Covered in the v2 document.
>>>>
>>>> Can you please let me know which text addresses my DISCUSS.
>>>>
>>>> https://www.i= etf.org/rfcdiff?url2=3Ddraft-perrault-behave-deprecate-nat-mib-v1-02
>>>>
>>>> Also, for the copyright and date, I was referring to the MIB description:
>>>>
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DESCRIPTION
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"This MIB module defines the generic managed objects
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 for NAT.
>>>>
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Copyright (C) The Internet Society (2014). This
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 version of this MIB module is part of RFC yyyy; see
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 the RFC itself for full legal notices."
>>>>
>>>>
>>>> Regards, Benoit
>>>>
>>>
>>> These are the remaining points for Benoit's Discus= s on this document, is
>>> that correct?
>>>
>>> Thanks,
>>>
>>> Spencer
>>>
>>>
>>>>
>>>> I started to file a DISCUSS on that very point. However, I was so
>>>> bothered by this difference that I actually compared the MIB modules
>>>> extracted from this draft and from RFC4008.
>>>> I see two occurences of this change: InetAddress (SIZE (4|16) versus
>>>> InetAddress
>>>> Why?
>>>>
>>>>
>>>>
>>>
>> .
>>
>



--089e013a13bc838e670519450e03-- From nobody Wed Jun 24 08:23:44 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 D86AB1A8ADA; Wed, 24 Jun 2015 08:23:42 -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 bQYl6IDKmmBZ; Wed, 24 Jun 2015 08:23:41 -0700 (PDT) Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com [IPv6:2607:f8b0:400c:c0f::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 207661A8794; Wed, 24 Jun 2015 08:23:41 -0700 (PDT) Received: by vnbg7 with SMTP id g7so6826230vnb.11; Wed, 24 Jun 2015 08:23:40 -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=hFqUNFQmKOc45J/Bd87VKjD49b+ESoYWQHBZhx5164Y=; b=LzB2AYsqmULGGD8P35VGds+DvlJA8Must7Z78NCwMImzvhiJrQOMhmLVIqXm7QqgF6 O/v+TnYLJwB0M41yw52HPjTnW3gYmH8mTiNg9ymsQUfiPLEnDT8Gvf6CQzA9vdNBEYlW GwaBQayAhM1+kQDxysZ819nAAeb5mKmdwcyBDTInhAQfoccHjB2WtOsBIVITzEMn5Q/1 lP1VLLbbEfeO+IjoVAeHBxKyW27ku58hd7Y20501ah3PU1b6Iv+L+3FK9+9FNxQehzSp 9NsbTESDq+dzS9+FUeAxwsenDEn5Kq/6+NxvgYcPxghQof3lTZTS5Ls4ZnPFn3tFcN2x dLvA== MIME-Version: 1.0 X-Received: by 10.52.88.111 with SMTP id bf15mr38031748vdb.20.1435159420279; Wed, 24 Jun 2015 08:23:40 -0700 (PDT) Received: by 10.31.195.6 with HTTP; Wed, 24 Jun 2015 08:23:40 -0700 (PDT) In-Reply-To: <558ACA5F.7000105@gmail.com> References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> <558A9E2F.6050506@cisco.com> <558ACA5F.7000105@gmail.com> Date: Wed, 24 Jun 2015 11:23:40 -0400 Message-ID: From: Spencer Dawkins at IETF To: Tom Taylor Content-Type: multipart/alternative; boundary=20cf307cfbe67122a105194517b9 Archived-At: Cc: "behave@ietf.org" , Tina Tsou , Jouni Korhonen , The IESG , Benoit Claise , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 15:23:43 -0000 --20cf307cfbe67122a105194517b9 Content-Type: text/plain; charset=UTF-8 Hi, Tom, On Wed, Jun 24, 2015 at 11:18 AM, Tom Taylor wrote: > OK, our messages crossed. I will take no further actions other than making > sure the copyright date is fixed. And double-crossed :-) Could you submit a version of the draft with the copyright date fix, and I can send an approval note for that? Spencer > Tom > > On 24/06/2015 8:10 AM, Benoit Claise wrote: > >> Dear all, >> >>> >>> >>> On Jun 24, 2015 04:51, "Benoit Claise" >> > wrote: >>> > >>> > Hi Tom, >>> > >>> >> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright >>> thing, it can be fixed in AUTH48. >>> >> >>> >> Reviewing the IESG evaluation, I note the suggestion to leave out >>> the MIB module definition itself and just have text saying (as Joel >>> suggested) that all objects are deprecated. Would people agree to >>> that? That would eliminate my fiddling with syntax to eliminate >>> SMILINT warnings. >>> >>> Forgot to reply to this one. >> I believe the draft makes sense as done right now. >> People might want to extract all MIB modules from RFC and load them all. >> This way, they would directly see in their MIB browser that the MIB >> objects are deprecated. >> >> Regards, Benoit >> >>> >>> So, two questions - >>> >>> - is the issue that changing the definition while deprecating the >>> objects is strange? >>> >>> - if the document just said "all objects are deprecated", would the >>> resulting MIB modules still produce SMILINT warnings? >>> >>> Obviously, I'm wondering if the right answer is to leave the syntax >>> unchanged, and point out that the syntax generates SMILINT warnings >>> whether the objects are deprecated or not, but since all this document >>> is doing is deprecating objects, the syntax is left unchanged, and >>> anyone who implements the V1 MIB now will have bigger problems than >>> the SMILINT warnings, but I don't know that's the right answer. >>> >>> ... > --20cf307cfbe67122a105194517b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Tom,

On Wed, Jun 24, 2015 at 11:18 AM, Tom Taylor <= tom.taylor.s= tds@gmail.com> wrote:
OK, o= ur messages crossed. I will take no further actions other than making sure = the copyright date is fixed.

And double-cro= ssed :-)

Could you submit a version of the draft w= ith the copyright date fix, and I can send an approval note for that?
=

Spencer
=C2=A0
Tom

On 24/06/2015 8:10 AM, Benoit Claise wrote:
Dear all,


On Jun 24, 2015 04:51, "Benoit Claise" <bclaise@cisco.com
<mailto:bclaise@c= isco.com>> wrote:
>
> Hi Tom,
>
>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyrigh= t
thing, it can be fixed in AUTH48.
>>
>> Reviewing the IESG evaluation, I note the suggestion to leave out<= br> the MIB module definition itself and just have text saying (as Joel
suggested) that all objects are deprecated. Would people agree to
that? That would eliminate my fiddling with syntax to eliminate
SMILINT warnings.

Forgot to reply to this one.
I believe the draft makes sense as done right now.
People might want to extract all MIB modules from RFC and load them all. This way, they would directly see in their MIB browser that the MIB
objects are deprecated.

Regards, Benoit

So, two questions -

- is the issue that changing the definition while deprecating the
objects is strange?

- if the document just said "all objects are deprecated", would t= he
resulting MIB modules still produce SMILINT warnings?

Obviously, I'm wondering if the right answer is to leave the syntax
unchanged, and point out that the syntax generates SMILINT warnings
whether the objects are deprecated or not, but since all this document
is doing is deprecating objects, the syntax is left unchanged, and
anyone who implements the V1 MIB now will have bigger problems than
the SMILINT warnings, but I don't know that's the right answer.

...

--20cf307cfbe67122a105194517b9-- From nobody Wed Jun 24 08:37:06 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 6C8CB1AC409 for ; Wed, 24 Jun 2015 08:37:04 -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] 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 5u_TMO33XDQE; Wed, 24 Jun 2015 08:37:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D71D1AC3E9; Wed, 24 Jun 2015 08:37:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , "Spencer Dawkins" , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150624153702.31622.3156.idtracker@ietfa.amsl.com> Date: Wed, 24 Jun 2015 08:37:02 -0700 Archived-At: Subject: [BEHAVE] New Version Notification - draft-perrault-behave-deprecate-nat-mib-v1-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 15:37:04 -0000 A new version (-04) has been submitted for draft-perrault-behave-deprecate-nat-mib-v1: https://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-04 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. IETF Secretariat. From nobody Wed Jun 24 08:40:31 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 578541ACD9B; Wed, 24 Jun 2015 08:40:27 -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 MqkjojXbT7gh; Wed, 24 Jun 2015 08:40:26 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 255CD1ACCFA; Wed, 24 Jun 2015 08:38:55 -0700 (PDT) Received: by igbiq7 with SMTP id iq7so99927725igb.1; Wed, 24 Jun 2015 08:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=h+qE9/h+nb4GQuGxBGGlUi02T0fjk4QOepmjRbP1cQs=; b=G33Zz87fQJ0qpLQhhjtUoj95XKn21s7in2CI6UBeiZalbvAzNxJVTrbqBNO+ZL94Sd hSFlyNu7x46xah6x2330ksNLrCH5OxcC787WcPLXeb0qQHqfimcvWmxEtjhpij1Jv6AN hEXOq2fvRJ14oZfw8AAZa6vS6/IB7SHBubJV5frUkG/OVrhcgxACPFcWqF/AYrtryJsN Mkw/bnvAJaySqtKWqSuANxQqiwUEFqCo7g2GgwZD7rnHJ4t4o7Dds8g0+S2fmprvasnG oGgnHVsB+sQ2maYg/Wv0kquVmsZGUmQen4TXV5pUzIFT9XuiuHpg6ANNeO1onJtRf/o6 IHyw== X-Received: by 10.50.64.244 with SMTP id r20mr3882105igs.33.1435160334719; Wed, 24 Jun 2015 08:38:54 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-6-50.tor.primus.ca. [173.206.6.50]) by mx.google.com with ESMTPSA id s28sm16141565ioi.31.2015.06.24.08.38.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 08:38:53 -0700 (PDT) To: Spencer Dawkins at IETF References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> <558A9E2F.6050506@cisco.com> <558ACA5F.7000105@gmail.com> From: Tom Taylor Message-ID: <558ACF0D.7030700@gmail.com> Date: Wed, 24 Jun 2015 11:38:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "behave@ietf.org" , Tina Tsou , Jouni Korhonen , The IESG , Benoit Claise , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 15:40:27 -0000 Done. Tom On 24/06/2015 11:23 AM, Spencer Dawkins at IETF wrote: > Hi, Tom, > > On Wed, Jun 24, 2015 at 11:18 AM, Tom Taylor > wrote: > >> OK, our messages crossed. I will take no further actions other than making >> sure the copyright date is fixed. > > > And double-crossed :-) > > Could you submit a version of the draft with the copyright date fix, and I > can send an approval note for that? > > Spencer > > ... From nobody Wed Jun 24 09:40:44 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 7DCEE1ACCDA for ; Wed, 24 Jun 2015 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 eFiUAXl8QpGU; Wed, 24 Jun 2015 09:40:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3721ACCE7; Wed, 24 Jun 2015 09:40:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Spencer Dawkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150624164041.23952.91801.idtracker@ietfa.amsl.com> Date: Wed, 24 Jun 2015 09:40:41 -0700 From: IETF Secretariat Archived-At: Subject: [BEHAVE] ID Tracker State Update Notice: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 16:40:43 -0000 IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation - Defer::AD Followup ID Tracker URL: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ From nobody Wed Jun 24 09:46:02 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 ADCE91B2B4D for ; Wed, 24 Jun 2015 09:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 ztYLVuR2UnXQ; Wed, 24 Jun 2015 09:46:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE77A1B2B3F; Wed, 24 Jun 2015 09:46:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Spencer Dawkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150624164600.27690.5629.idtracker@ietfa.amsl.com> Date: Wed, 24 Jun 2015 09:46:00 -0700 From: IETF Secretariat Archived-At: Subject: [BEHAVE] ID Tracker State Update Notice: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 16:46:01 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ From nobody Wed Jun 24 11:06:29 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 286EC1ACDD7 for ; Wed, 24 Jun 2015 11:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 ccoAOkl4efwG; Wed, 24 Jun 2015 11:06:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF1E1ACDCD; Wed, 24 Jun 2015 11:06:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Spencer Dawkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150624180626.11751.79516.idtracker@ietfa.amsl.com> Date: Wed, 24 Jun 2015 11:06:26 -0700 From: IETF Secretariat Archived-At: Subject: [BEHAVE] ID Tracker State Update Notice: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 18:06:28 -0000 IANA action state changed to In Progress ID Tracker URL: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ From nobody Wed Jun 24 15:07: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 F29E21A87B8 for ; Wed, 24 Jun 2015 15:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01] 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 Jxw7J62qiZNb for ; Wed, 24 Jun 2015 15:07:19 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4760C1A8700 for ; Wed, 24 Jun 2015 15:07:19 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-01v.sys.comcast.net with comcast id kN7A1q00456HXL001N7JjB; Wed, 24 Jun 2015 22:07:18 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-po-12v.sys.comcast.net with comcast id kN7H1q0072yZEBF01N7H34; Wed, 24 Jun 2015 22:07:18 +0000 From: "ietfdbh" To: "'Benoit Claise'" , "'Spencer Dawkins at IETF'" References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> <558A9E2F.6050506@cisco.com> In-Reply-To: <558A9E2F.6050506@cisco.com> Date: Wed, 24 Jun 2015 18:07:17 -0400 Message-ID: <063a01d0aeca$22d44d70$687ce850$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_063B_01D0AEA8.9BC76860" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE8SDcWWctaN8P1aLX/Muo/6+XcOQMfBJCfAxUfQ0UCbdTAewH3Pz7fASSqBKEDA8vYsgLHd9IxAmc14UMCaLMqjp4yOY1A Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1435183638; bh=ACkT87lrJnjY2Jw5eX3l7HcHXkVszme0XvTYDYQ3Z/k=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=AFDsRRWj7iHsiiS75AkU6+UeIqInjWEmXhEmCJBqVHiFf6XYzSs1GM4Q9F2UCwMyM SiLQpf92Lw13Fx2g6IItHfrcUeo+67f8jpeyxDdWUmS+4s+zDRLjCo2x75vnZhy7VW B9iTWrBUATeNvdV9O7wa7hS7x5u/WuloAoSe0Jzf9t+XqZtzAykux80M7fzhcjFJ5a 2zPMlVb4ncTylZvZ+2TZjWWDMX05Xw2U0/PecBxusanTAbwqLxvBkz1o1rNfnf6Trq 2vYNOdoMH+WvBMhCkZ5DUNLuYt771YkIXbZIOoUIplP+pPCFfDbgqRvCWnsK/MNhZs TyWF+7qWfQj3A== Archived-At: Cc: behave@ietf.org, 'Tina Tsou' , 'Jouni Korhonen' , 'The IESG' , 'Tom Taylor' , sperreault@jive.ca Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 22:07:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_063B_01D0AEA8.9BC76860 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 =20 As a MIB Doctor, I am not sure it would be =E2=80=9Clegal=E2=80=9D per = RFC2578 to alter the status of the objects without re-publishing the = object definition. I have not researching the =E2=80=9Clegal=E2=80=9D arguments thoroughly, = but I think it would not be =E2=80=9Clegal=E2=80=9D. =20 As a (past) implementer of network management software, I think it is = important that an NMS can import the current status of each object from = the MIB database =E2=80=9Cschema=E2=80=9D into the local database format = being used internally. An RFC that simply says =E2=80=9Call these = objects are deprecated=E2=80=9D doesn=E2=80=99t meet the requirements of = that situation. =20 David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Wednesday, June 24, 2015 8:10 AM To: Spencer Dawkins at IETF Cc: behave@ietf.org; sperreault@jive.ca; The IESG; Jouni Korhonen; = ietfdbh; Tom Taylor; Tina Tsou Subject: Re: [BEHAVE] Benoit Claise's Discuss on = draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and = COMMENT) =20 Dear all,=20 On Jun 24, 2015 04:51, "Benoit Claise" wrote: > > Hi Tom, > >> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright = thing, it can be fixed in AUTH48. >> >> Reviewing the IESG evaluation, I note the suggestion to leave out the = MIB module definition itself and just have text saying (as Joel = suggested) that all objects are deprecated. Would people agree to that? = That would eliminate my fiddling with syntax to eliminate SMILINT = warnings. Forgot to reply to this one. I believe the draft makes sense as done right now. People might want to extract all MIB modules from RFC and load them all. This way, they would directly see in their MIB browser that the MIB = objects are deprecated. Regards, Benoit So, two questions -=20 - is the issue that changing the definition while deprecating the = objects is strange? - if the document just said "all objects are deprecated", would the = resulting MIB modules still produce SMILINT warnings? Obviously, I'm wondering if the right answer is to leave the syntax = unchanged, and point out that the syntax generates SMILINT warnings = whether the objects are deprecated or not, but since all this document = is doing is deprecating objects, the syntax is left unchanged, and = anyone who implements the V1 MIB now will have bigger problems than the = SMILINT warnings, but I don't know that's the right answer. >> Regarding the Discuss: the Security Considerations section currently = reads: >> >> "All objects in this MIB module have been deprecated. As a result, >> security considerations in [I-D.ietf-behave-nat-mib-v2] apply >> instead. Amongst other matters, these considerations cover the = case >> where both this MIB module and NAT-MIB-V2 are present. In fact, = such >> a situation is unlikely because [RFC4008], as a MIB module = oriented >> toward configuration, was overtaken by events and saw little >> implementation." >> >> Was this too condensed? > > Not what I was expecting, but I guess it does the job to clear the = DISCUSS. Clearing now. Thank you, of course. Spencer > Regards, Benoit > > >> >> >> Tom >> >> On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote: >>> >>> Hi, Tom, >>> >>> Just keeping up ... >>> >>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise = wrote: >>> >>>> Thanks Tom, >>>> ... >>>> >>>> >>>> - This point above is in line with Jouni's feedback. >>>> * There is also no text about operational and management = implications >>>> related to deprecation process of the old MIB and migrating to = the >>>> new (to be approved) NAT-MIB-v2). >>>> >>>> >>>> [PTT] Covered in the v2 document. >>>> >>>> Can you please let me know which text addresses my DISCUSS. >>>> >>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-perrault-behave-deprecate-nat-m= ib-v1-02=20 >>>> >>>> Also, for the copyright and date, I was referring to the MIB = description: >>>> >>>> DESCRIPTION >>>> "This MIB module defines the generic managed = objects >>>> for NAT. >>>> >>>> Copyright (C) The Internet Society (2014). This >>>> version of this MIB module is part of RFC yyyy; = see >>>> the RFC itself for full legal notices." >>>> >>>> >>>> Regards, Benoit >>>> >>> >>> These are the remaining points for Benoit's Discuss on this = document, is >>> that correct? >>> >>> Thanks, >>> >>> Spencer >>> >>> >>>> >>>> I started to file a DISCUSS on that very point. However, I was so >>>> bothered by this difference that I actually compared the MIB = modules >>>> extracted from this draft and from RFC4008. >>>> I see two occurences of this change: InetAddress (SIZE (4|16) = versus >>>> InetAddress >>>> Why? >>>> >>>> >>>> >>> >> . >> > =20 ------=_NextPart_000_063B_01D0AEA8.9BC76860 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1

 

As a MIB Doctor, I am not sure it would be =E2=80=9Clegal=E2=80=9D = per RFC2578 to alter the status of the objects without re-publishing the = object definition.

I have not researching the =E2=80=9Clegal=E2=80=9D arguments = thoroughly, but I think it would not be = =E2=80=9Clegal=E2=80=9D.

 

As a (past) implementer of network management software, I think it is = important that an NMS can import the current status of each object from = the MIB database =E2=80=9Cschema=E2=80=9D into the local database format = being used internally. An RFC that simply says =E2=80=9Call these = objects are deprecated=E2=80=9D doesn=E2=80=99t meet the requirements of = that situation.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: = Wednesday, June 24, 2015 8:10 AM
To: Spencer Dawkins at = IETF
Cc: behave@ietf.org; sperreault@jive.ca; The IESG; Jouni = Korhonen; ietfdbh; Tom Taylor; Tina Tsou
Subject: Re: [BEHAVE] = Benoit Claise's Discuss on = draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and = COMMENT)

 

Dear = all,


On Jun 24, 2015 = 04:51, "Benoit Claise" <bclaise@cisco.com> = wrote:
>
> Hi Tom,
>
>> Yes, I believe so. If = the RFC Ed. doesn't pick up the copyright thing, it can be fixed in = AUTH48.
>>
>> Reviewing the IESG evaluation, I note = the suggestion to leave out the MIB module definition itself and just = have text saying (as Joel suggested) that all objects are deprecated. = Would people agree to that? That would eliminate my fiddling with syntax = to eliminate SMILINT warnings.

Forgot to reply to this one.
I believe the draft = makes sense as done right now.
People might want to extract all MIB = modules from RFC and load them all.
This way, they would directly see = in their MIB browser that the MIB objects are = deprecated.

Regards, Benoit

So, two = questions -

- is the issue that changing the = definition while deprecating the objects is strange?

- = if the document just said "all objects are deprecated", would = the resulting MIB modules still produce SMILINT = warnings?

Obviously, I'm wondering if the right answer = is to leave the syntax unchanged, and point out that the syntax = generates SMILINT warnings whether the objects are deprecated or not, = but since all this document is doing is deprecating objects, the syntax = is left unchanged, and anyone who implements the V1 MIB now will have = bigger problems than the SMILINT warnings, but I don't know that's the = right answer.

>> Regarding the Discuss: the = Security Considerations section currently reads:
>>
>> =   "All objects in this MIB module have been deprecated.  = As a result,
>>    security considerations in = [I-D.ietf-behave-nat-mib-v2] apply
>>   =  instead.  Amongst other matters, these considerations cover = the case
>>    where both this MIB module and = NAT-MIB-V2 are present.  In fact, such
>>    a = situation is unlikely because [RFC4008], as a MIB module = oriented
>>    toward configuration, was overtaken by = events and saw little
>>   =  implementation."
>>
>> Was this too = condensed?
>
> Not what I was expecting, but I guess it does = the job to clear the DISCUSS. Clearing now.

Thank you, = of course.

Spencer

> Regards, = Benoit
>
>
>>
>>
>> = Tom
>>
>> On 22/06/2015 12:39 PM, Spencer Dawkins at = IETF wrote:
>>>
>>> Hi, = Tom,
>>>
>>> Just keeping up = ...
>>>
>>> On Mon, Jun 22, 2015 at 2:51 AM, = Benoit Claise <bclaise@cisco.com> = wrote:
>>>
>>>>   Thanks = Tom,
>>>> = ...
>>>>
>>>>
>>>> - This = point above is in line with Jouni's feedback.
>>>> * = There is also no text about operational and management = implications
>>>>     related to deprecation = process of the old MIB and migrating to the
>>>>   =   new (to be approved) = NAT-MIB-v2).
>>>>
>>>>
>>>> = [PTT] Covered in the v2 = document.
>>>>
>>>> Can you please let me = know which text addresses my = DISCUSS.
>>>>
>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-perrault-beha= ve-deprecate-nat-mib-v1-02
>>>>
>>>> = Also, for the copyright and date, I was referring to the MIB = description:
>>>>
>>>>     =      DESCRIPTION
>>>>       =            "This MIB module defines = the generic managed objects
>>>>       =             for = NAT.
>>>>
>>>>         =           Copyright (C) The Internet Society = (2014). This
>>>>           =         version of this MIB module is part of RFC = yyyy; see
>>>>             =       the RFC itself for full legal = notices."
>>>>
>>>>
>>>>= ; Regards, Benoit
>>>>
>>>
>>> = These are the remaining points for Benoit's Discuss on this document, = is
>>> that correct?
>>>
>>> = Thanks,
>>>
>>> = Spencer
>>>
>>>
>>>>
>>&g= t;> I started to file a DISCUSS on that very point. However, I was = so
>>>> bothered by this difference that I actually = compared the MIB modules
>>>> extracted from this draft = and from RFC4008.
>>>> I see two occurences of this = change: InetAddress (SIZE (4|16) versus
>>>> = InetAddress
>>>> = Why?
>>>>
>>>>
>>>>
>&= gt;>
>> .
>>
>

 

------=_NextPart_000_063B_01D0AEA8.9BC76860-- From nobody Wed Jun 24 15:18:52 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 5B92F1B2E67 for ; Wed, 24 Jun 2015 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, 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 Qp7Ees_UmpFa for ; Wed, 24 Jun 2015 15:18:47 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FC81A87B8 for ; Wed, 24 Jun 2015 15:18:46 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-05v.sys.comcast.net with comcast id kNHz1q0054tLnxL01NJmFT; Wed, 24 Jun 2015 22:18:46 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-po-02v.sys.comcast.net with comcast id kNJk1q00S2yZEBF01NJlDg; Wed, 24 Jun 2015 22:18:46 +0000 From: "ietfdbh" To: "'Tom Taylor'" , "'Spencer Dawkins at IETF'" , "'Benoit Claise'" References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> <558AC9EA.6070907@gmail.com> In-Reply-To: <558AC9EA.6070907@gmail.com> Date: Wed, 24 Jun 2015 18:18:44 -0400 Message-ID: <064f01d0aecb$bcd84ab0$3688e010$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE8SDcWWctaN8P1aLX/Muo/6+XcOQMfBJCfAxUfQ0UCbdTAewH3Pz7fASSqBKEDA8vYsgLHd9IxAmc14UMBYKkaL546e/Vg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1435184326; bh=vzFq7tIsLd33eEL9PUcFyGeYlulkeolGl6qdHATYbwI=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=YjNtMcYe4xy23laL8lQIKSoTjYiwNoSRN4O+u/c+0GFJipKtB4ycNe5ZmywEl2yqt 6xlnNTlkzCfT+LFjInAMsTSCApTMOWg8Egsv+kTUtDlGBLLyD+v8l1soNSUgqrMMu8 Qltd/Clc/zMcdrwt7AzbIkQSkFxdXKQahRBBiqUERvc5edOqhBJXDAZ6W5y1SP1eC3 IUHA2VUoIkIwcdfKhJebzpf6DlUJjn4XxxV8ZMjaQFQwYdzU9GgD0Q6wkr9fU0YTuU C2XWc44F+jaPR4x7y9CxNKLru3dfO7ygKq8XSIK5RNY6qrVfVNu2wzzJK/9qHgFmbC 9Ag7U+JAJAnwQ== Archived-At: Cc: sperreault@jive.ca, 'Jouni Korhonen' , behave@ietf.org, 'The IESG' , 'Tina Tsou' Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 22:18:48 -0000 I recommend leaving the object definitions unchanged, except for the = status clause. I think some of the SMILINT rules were not set when = RFC4008 was published. The consensus of the MIB Doctors wasn't "set" = until RFC4181, and SMILINT both helped drive the consensus, pre-4181, = and automates the consensus, post-4181. RFC2578 recommends explaining in each description clause why the object = is deprecated. I personally feel that having one statement in the module-identity = explaining the deprecation could suffice, this discussion is running = parallel to the discussion of why we need to change the status in each = object and re-publish. Given that the per-object deprecation is = important so an NMS can import that information, it would be helpful to = operators to look at the imported deprecated object and see the = description of why it was deprecated (Some NMS's bring up the object = definition/description as a sort of man-page for each object, so an = operator doesn't need to hunt down the info in RFCs while fighting = network fires. So I think it would be justified to put an explanation = into each object description.=20 I would be satisfied with a textual reference to the NAT-V2-MIB and a = REFERENCE clause to the new RFC, in each deprecated object. This would = make for a normative reference, I think. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: Wednesday, June 24, 2015 11:17 AM > To: Spencer Dawkins at IETF; Benoit Claise > Cc: behave@ietf.org; sperreault@jive.ca; The IESG; Jouni Korhonen; = ietfdbh; > Tina Tsou > Subject: Re: [BEHAVE] Benoit Claise's Discuss on = draft-perrault-behave- > deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) >=20 > Below with [PTT] >=20 > On 24/06/2015 6:26 AM, Spencer Dawkins at IETF wrote: > > On Jun 24, 2015 04:51, "Benoit Claise" wrote: > >> > >> Hi Tom, > >> > >>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright = thing, > > it can be fixed in AUTH48. > >>> > >>> Reviewing the IESG evaluation, I note the suggestion to leave out = the > > MIB module definition itself and just have text saying (as Joel = suggested) > > that all objects are deprecated. Would people agree to that? That = would > > eliminate my fiddling with syntax to eliminate SMILINT warnings. > > > > So, two questions - > > > > - is the issue that changing the definition while deprecating the = objects > > is strange? >=20 > [PTT] Yes, per guidelines quoted by Benoit. > > > > - if the document just said "all objects are deprecated", would the > > resulting MIB modules still produce SMILINT warnings? >=20 > [PTT] Yes. I just verified that RFC 4008 generates the following = warnings > mibs/NAT-MIB:932: [5] {index-exceeds-too-large} warning: index of row > `natAddrBindEntry' can exceed OID size limit by 141 subidentifier(s) > mibs/NAT-MIB:1162: [5] {index-exceeds-too-large} warning: index of row > `natAddrPortBindEntry' can exceed OID size limit by 143 = subidentifier(s) > > > > Obviously, I'm wondering if the right answer is to leave the syntax > > unchanged, and point out that the syntax generates SMILINT warnings > whether > > the objects are deprecated or not, but since all this document is = doing is > > deprecating objects, the syntax is left unchanged, and anyone who > > implements the V1 MIB now will have bigger problems than the SMILINT > > warnings, but I don't know that's the right answer. > > > ... From nobody Wed Jun 24 15:30:43 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 9D03D1B2EBC; Wed, 24 Jun 2015 15:30: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 PzWMwFKfDSvd; Wed, 24 Jun 2015 15:30:40 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (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 C4AFD1B2EBB; Wed, 24 Jun 2015 15:30:40 -0700 (PDT) Received: by ieqy10 with SMTP id y10so43073127ieq.0; Wed, 24 Jun 2015 15:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=WGfvMbJznrGbcaHicJhNLU8MriROdVNKoGyvzrdpmOw=; b=RAkt7p4p41hBtTpNJCoCFIci4AW1uugs6oyRoYnQI7bJb8xyjiVbQERbX6JpPA2PeP /1ON7LTwI145ym+LKd7spUeW9BVc59QiMKXO9PJN+QPu7TDkSR5uSAOPetQIm3YEDtzZ FD3MtcT/kf8L0MPZE6atKsDAhH1efQz1A4uHm9L1KOgDHBZpsZbqExRpYCj9AxD4pCUe yBqImDamdkj5X/PnCGxFnXMZrTn1FXTiBmXL0CpAFfTS9SoNYWahdTjd3DMAjuEq9g6g Tyrek65JtczlwCGwm42pjfCSifLSxvTuzULxucKWgfP4MPIUFI53fCf+MvFe0XWIhFyA KLNA== X-Received: by 10.107.14.65 with SMTP id 62mr44881963ioo.67.1435185040321; Wed, 24 Jun 2015 15:30:40 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-6-50.tor.primus.ca. [173.206.6.50]) by mx.google.com with ESMTPSA id eg3sm57300igb.0.2015.06.24.15.30.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 15:30:39 -0700 (PDT) To: ietfdbh , 'Spencer Dawkins at IETF' , 'Benoit Claise' References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> <558AC9EA.6070907@gmail.com> <064f01d0aecb$bcd84ab0$3688e010$@comcast.net> From: Tom Taylor Message-ID: <558B2F8F.7070008@gmail.com> Date: Wed, 24 Jun 2015 18:30:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <064f01d0aecb$bcd84ab0$3688e010$@comcast.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sperreault@jive.ca, 'Jouni Korhonen' , behave@ietf.org, 'The IESG' , 'Tina Tsou' Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 24 Jun 2015 22:30:42 -0000 OK, if others accept this, I guess I have one more editing pass. And I should close out all the issues I set up inb the issue tracker. Tom On 24/06/2015 6:18 PM, ietfdbh wrote: > I recommend leaving the object definitions unchanged, except for the status clause. I think some of the SMILINT rules were not set when RFC4008 was published. The consensus of the MIB Doctors wasn't "set" until RFC4181, and SMILINT both helped drive the consensus, pre-4181, and automates the consensus, post-4181. > > RFC2578 recommends explaining in each description clause why the object is deprecated. > I personally feel that having one statement in the module-identity explaining the deprecation could suffice, this discussion is running parallel to the discussion of why we need to change the status in each object and re-publish. Given that the per-object deprecation is important so an NMS can import that information, it would be helpful to operators to look at the imported deprecated object and see the description of why it was deprecated (Some NMS's bring up the object definition/description as a sort of man-page for each object, so an operator doesn't need to hunt down the info in RFCs while fighting network fires. So I think it would be justified to put an explanation into each object description. > > I would be satisfied with a textual reference to the NAT-V2-MIB and a REFERENCE clause to the new RFC, in each deprecated object. This would make for a normative reference, I think. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >> -----Original Message----- >> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] >> Sent: Wednesday, June 24, 2015 11:17 AM >> To: Spencer Dawkins at IETF; Benoit Claise >> Cc: behave@ietf.org; sperreault@jive.ca; The IESG; Jouni Korhonen; ietfdbh; >> Tina Tsou >> Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave- >> deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) >> >> Below with [PTT] >> >> On 24/06/2015 6:26 AM, Spencer Dawkins at IETF wrote: >>> On Jun 24, 2015 04:51, "Benoit Claise" wrote: >>>> >>>> Hi Tom, >>>> >>>>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, >>> it can be fixed in AUTH48. >>>>> >>>>> Reviewing the IESG evaluation, I note the suggestion to leave out the >>> MIB module definition itself and just have text saying (as Joel suggested) >>> that all objects are deprecated. Would people agree to that? That would >>> eliminate my fiddling with syntax to eliminate SMILINT warnings. >>> >>> So, two questions - >>> >>> - is the issue that changing the definition while deprecating the objects >>> is strange? >> >> [PTT] Yes, per guidelines quoted by Benoit. >>> >>> - if the document just said "all objects are deprecated", would the >>> resulting MIB modules still produce SMILINT warnings? >> >> [PTT] Yes. I just verified that RFC 4008 generates the following warnings >> mibs/NAT-MIB:932: [5] {index-exceeds-too-large} warning: index of row >> `natAddrBindEntry' can exceed OID size limit by 141 subidentifier(s) >> mibs/NAT-MIB:1162: [5] {index-exceeds-too-large} warning: index of row >> `natAddrPortBindEntry' can exceed OID size limit by 143 subidentifier(s) >>> >>> Obviously, I'm wondering if the right answer is to leave the syntax >>> unchanged, and point out that the syntax generates SMILINT warnings >> whether >>> the objects are deprecated or not, but since all this document is doing is >>> deprecating objects, the syntax is left unchanged, and anyone who >>> implements the V1 MIB now will have bigger problems than the SMILINT >>> warnings, but I don't know that's the right answer. >>> >> ... > > From nobody Wed Jun 24 18:25:07 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 783061A1AC9; Wed, 24 Jun 2015 18:25:02 -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 4KfwbJgLsIvY; Wed, 24 Jun 2015 18:25:00 -0700 (PDT) Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::22e]) (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 EA2D51A1A96; Wed, 24 Jun 2015 18:24:59 -0700 (PDT) Received: by vnbf7 with SMTP id f7so8867982vnb.7; Wed, 24 Jun 2015 18:24:59 -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=Mfb8A9IzoIPXGV3V4ShKBJ88pQCnqObp+OGTDHkCTJo=; b=07HS7enwVwy1HQJ+JRU2QjFjbE2IIUmMnTelD8XMPtguoHyOaZx6wd+7ga0agBOl/8 Jp3bnUdG1Y01Tfs7b8z3lOArHqUQSUi2d1neHrNjUElQViydmG5guwTS+LAf5t35mv2P ZHooFHW1yk5F/cyNOmF9ZNFLddbgabbeHUzvxA4iZijYG5/8dmHGs7/OuHOhR0TxlmyT aVdHEyGXinw3f0GX7CYlSnWURpOyC/lB2q60Vc6LaDoTpuYJEaN0EMyyl303IjajLlXw JbyvJKiiFbf915AqBLpaD1d4w4vbL+CYj3i1nPFHzKm5f0AqyAZAmReInN9vDx9V0Fbu SylA== MIME-Version: 1.0 X-Received: by 10.52.114.230 with SMTP id jj6mr26624208vdb.66.1435195499164; Wed, 24 Jun 2015 18:24:59 -0700 (PDT) Received: by 10.31.195.6 with HTTP; Wed, 24 Jun 2015 18:24:58 -0700 (PDT) Received: by 10.31.195.6 with HTTP; Wed, 24 Jun 2015 18:24:58 -0700 (PDT) In-Reply-To: <558B2F8F.7070008@gmail.com> References: <20150608134117.30091.62236.idtracker@ietfa.amsl.com> <001501d0a20e$b31c90e0$1955b2a0$@comcast.net> <5575EA98.1080009@cisco.com> <557EEDCF.9000506@gmail.com> <5587B06C.1080507@cisco.com> <5589C2E3.7050002@gmail.com> <558A6F72.3060203@cisco.com> <558AC9EA.6070907@gmail.com> <064f01d0aecb$bcd84ab0$3688e010$@comcast.net> <558B2F8F.7070008@gmail.com> Date: Wed, 24 Jun 2015 21:24:58 -0400 Message-ID: From: Spencer Dawkins at IETF To: Tom Taylor Content-Type: multipart/alternative; boundary=bcaec5489e45e93e5f05194d7d10 Archived-At: Cc: behave@ietf.org, Tina Tsou , Jouni Korhonen , iesg@ietf.org, Benoit Claise , sperreault@jive.ca, ietfdbh Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) 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, 25 Jun 2015 01:25:02 -0000 --bcaec5489e45e93e5f05194d7d10 Content-Type: text/plain; charset=UTF-8 So, I was perhaps jumping a gun? I sent the approval note for this draft earlier today. Should I be asking the IESG Secretary to hold this document while I make sure we're in sync? Spencer On Jun 24, 2015 18:30, "Tom Taylor" wrote: > > OK, if others accept this, I guess I have one more editing pass. And I should close out all the issues I set up inb the issue tracker. > > Tom > > > On 24/06/2015 6:18 PM, ietfdbh wrote: >> >> I recommend leaving the object definitions unchanged, except for the status clause. I think some of the SMILINT rules were not set when RFC4008 was published. The consensus of the MIB Doctors wasn't "set" until RFC4181, and SMILINT both helped drive the consensus, pre-4181, and automates the consensus, post-4181. >> >> RFC2578 recommends explaining in each description clause why the object is deprecated. >> I personally feel that having one statement in the module-identity explaining the deprecation could suffice, this discussion is running parallel to the discussion of why we need to change the status in each object and re-publish. Given that the per-object deprecation is important so an NMS can import that information, it would be helpful to operators to look at the imported deprecated object and see the description of why it was deprecated (Some NMS's bring up the object definition/description as a sort of man-page for each object, so an operator doesn't need to hunt down the info in RFCs while fighting network fires. So I think it would be justified to put an explanation into each object description. >> >> I would be satisfied with a textual reference to the NAT-V2-MIB and a REFERENCE clause to the new RFC, in each deprecated object. This would make for a normative reference, I think. >> >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >>> >>> -----Original Message----- >>> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] >>> Sent: Wednesday, June 24, 2015 11:17 AM >>> To: Spencer Dawkins at IETF; Benoit Claise >>> Cc: behave@ietf.org; sperreault@jive.ca; The IESG; Jouni Korhonen; ietfdbh; >>> Tina Tsou >>> Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave- >>> deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT) >>> >>> Below with [PTT] >>> >>> On 24/06/2015 6:26 AM, Spencer Dawkins at IETF wrote: >>>> >>>> On Jun 24, 2015 04:51, "Benoit Claise" wrote: >>>>> >>>>> >>>>> Hi Tom, >>>>> >>>>>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, >>>> >>>> it can be fixed in AUTH48. >>>>>> >>>>>> >>>>>> Reviewing the IESG evaluation, I note the suggestion to leave out the >>>> >>>> MIB module definition itself and just have text saying (as Joel suggested) >>>> that all objects are deprecated. Would people agree to that? That would >>>> eliminate my fiddling with syntax to eliminate SMILINT warnings. >>>> >>>> So, two questions - >>>> >>>> - is the issue that changing the definition while deprecating the objects >>>> is strange? >>> >>> >>> [PTT] Yes, per guidelines quoted by Benoit. >>>> >>>> >>>> - if the document just said "all objects are deprecated", would the >>>> resulting MIB modules still produce SMILINT warnings? >>> >>> >>> [PTT] Yes. I just verified that RFC 4008 generates the following warnings >>> mibs/NAT-MIB:932: [5] {index-exceeds-too-large} warning: index of row >>> `natAddrBindEntry' can exceed OID size limit by 141 subidentifier(s) >>> mibs/NAT-MIB:1162: [5] {index-exceeds-too-large} warning: index of row >>> `natAddrPortBindEntry' can exceed OID size limit by 143 subidentifier(s) >>>> >>>> >>>> Obviously, I'm wondering if the right answer is to leave the syntax >>>> unchanged, and point out that the syntax generates SMILINT warnings >>> >>> whether >>>> >>>> the objects are deprecated or not, but since all this document is doing is >>>> deprecating objects, the syntax is left unchanged, and anyone who >>>> implements the V1 MIB now will have bigger problems than the SMILINT >>>> warnings, but I don't know that's the right answer. >>>> >>> ... >> >> >> --bcaec5489e45e93e5f05194d7d10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So, I was perhaps jumping a gun?

I sent the approval note for this draft earlier today.

Should I be asking the IESG Secretary to hold this document = while I make sure we're in sync?

Spencer

On Jun 24, 2015 18:30, "Tom Taylor" <tom.taylor.stds@gmail.com> wrote:=
>
> OK, if others accept this, I guess I have one more editing pass. And I= should close out all the issues I set up inb the issue tracker.
>
> Tom
>
>
> On 24/06/2015 6:18 PM, ietfdbh wrote:
>>
>> I recommend leaving the object definitions unchanged, except for t= he status clause. I think some of the SMILINT rules were not set when RFC40= 08 was published. The consensus of the MIB Doctors wasn't "set&quo= t; until RFC4181, and SMILINT both helped drive the consensus, pre-4181, an= d automates the consensus, post-4181.
>>
>> RFC2578 recommends explaining in each description clause why the o= bject is deprecated.
>> I personally feel that having one statement in the module-identity= explaining the deprecation could suffice, this discussion is running paral= lel to the discussion of why we need to change the status in each object an= d re-publish. Given that the per-object deprecation is important so an NMS = can import that information, it would be helpful to operators to look at th= e imported deprecated object and see the description of why it was deprecat= ed (Some NMS's bring up the object definition/description as a sort of = man-page for each object, so an operator doesn't need to hunt down the = info in RFCs while fighting network fires. So I think it would be justified= to put an explanation into each object description.
>>
>> I would be satisfied with a textual reference to the NAT-V2-MIB an= d a REFERENCE clause to the new RFC, in each deprecated object. This would = make for a normative reference, I think.
>>
>> David Harrington
>> ietfdbh@comcast.net
>> +1-603-828-1401
>>>
>>> -----Original Message-----
>>> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]
>>> Sent: Wednesday, June 24, 2015 11:17 AM
>>> To: Spencer Dawkins at IETF; Benoit Claise
>>> Cc: behave@ietf.org; sperreault@jive.ca; The IESG; Jouni= Korhonen; ietfdbh;
>>> Tina Tsou
>>> Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-per= rault-behave-
>>> deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT)
>>>
>>> Below with [PTT]
>>>
>>> On 24/06/2015 6:26 AM, Spencer Dawkins at IETF wrote:
>>>>
>>>> On Jun 24, 2015 04:51, "Benoit Claise" <bclaise@cisco.com> wrote:
>>>>>
>>>>>
>>>>> Hi Tom,
>>>>>
>>>>>> Yes, I believe so. If the RFC Ed. doesn't pick= up the copyright thing,
>>>>
>>>> it can be fixed in AUTH48.
>>>>>>
>>>>>>
>>>>>> Reviewing the IESG evaluation, I note the suggesti= on to leave out the
>>>>
>>>> MIB module definition itself and just have text saying (as= Joel suggested)
>>>> that all objects are deprecated. Would people agree to tha= t? That would
>>>> eliminate my fiddling with syntax to eliminate SMILINT war= nings.
>>>>
>>>> So, two questions -
>>>>
>>>> - is the issue that changing the definition while deprecat= ing the objects
>>>> is strange?
>>>
>>>
>>> [PTT] Yes, per guidelines quoted by Benoit.
>>>>
>>>>
>>>> - if the document just said "all objects are deprecat= ed", would the
>>>> resulting MIB modules still produce SMILINT warnings?
>>>
>>>
>>> [PTT] Yes. I just verified that RFC 4008 generates the followi= ng warnings
>>> mibs/NAT-MIB:932: [5] {index-exceeds-too-large} warning: index= of row
>>> `natAddrBindEntry' can exceed OID size limit by 141 subide= ntifier(s)
>>> mibs/NAT-MIB:1162: [5] {index-exceeds-too-large} warning: inde= x of row
>>> `natAddrPortBindEntry' can exceed OID size limit by 143 su= bidentifier(s)
>>>>
>>>>
>>>> Obviously, I'm wondering if the right answer is to lea= ve the syntax
>>>> unchanged, and point out that the syntax generates SMILINT= warnings
>>>
>>> whether
>>>>
>>>> the objects are deprecated or not, but since all this docu= ment is doing is
>>>> deprecating objects, the syntax is left unchanged, and any= one who
>>>> implements the V1 MIB now will have bigger problems than t= he SMILINT
>>>> warnings, but I don't know that's the right answer= .
>>>>
>>> ...
>>
>>
>>

--bcaec5489e45e93e5f05194d7d10-- From nobody Thu Jun 25 12:10:09 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 40ABA1ACD13 for ; Thu, 25 Jun 2015 12:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 ddzpHzwNFbPD; Thu, 25 Jun 2015 12:10:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 088531ACD0B; Thu, 25 Jun 2015 12:10:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Spencer Dawkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150625191006.10052.10025.idtracker@ietfa.amsl.com> Date: Thu, 25 Jun 2015 12:10:06 -0700 From: IETF Secretariat Archived-At: Subject: [BEHAVE] ID Tracker State Update Notice: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 19:10:07 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ From nobody Sun Jun 28 16:30: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 0F84A1B3058 for ; Sun, 28 Jun 2015 16:29:56 -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] 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 oworwSNeIYdZ; Sun, 28 Jun 2015 16:29:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8F81B304F; Sun, 28 Jun 2015 16:29:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , "Spencer Dawkins" , , "RFC Editor" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150628232952.30506.19692.idtracker@ietfa.amsl.com> Date: Sun, 28 Jun 2015 16:29:52 -0700 Archived-At: Subject: [BEHAVE] New Version Notification - draft-perrault-behave-deprecate-nat-mib-v1-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 23:29:56 -0000 A new version (-05) has been submitted for draft-perrault-behave-deprecate-nat-mib-v1: https://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-05 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. IETF Secretariat. From nobody Mon Jun 29 14:05:11 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 CBE591B3441 for ; Mon, 29 Jun 2015 14:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 0SjXoX8Ywyc3; Mon, 29 Jun 2015 14:05:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4EC1B343E; Mon, 29 Jun 2015 14:05:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Spencer Dawkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150629210508.7935.28521.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 14:05:08 -0700 From: IETF Secretariat Archived-At: Subject: [BEHAVE] ID Tracker State Update Notice: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 21:05:10 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/