From nobody Wed Aug 20 09:48:59 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7E01A0487 for ; Wed, 20 Aug 2014 09:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4OLifRDgGa5 for ; Wed, 20 Aug 2014 09:48:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B381F1A0468 for ; Wed, 20 Aug 2014 09:48:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A041E180480; Wed, 20 Aug 2014 09:48:53 -0700 (PDT) To: xing@cernet.edu.cn, congxiao@cernet.edu.cn, fred@cisco.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, dwing@cisco.com, dthaler@microsoft.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140820164853.A041E180480@rfc-editor.org> Date: Wed, 20 Aug 2014 09:48:53 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/behave/tiU-6QEiQDH_08UFlrXSmcg0fq4 Cc: fgont@si6networks.com, behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC6145 (4090) 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, 20 Aug 2014 16:48:57 -0000 The following errata report has been submitted for RFC6145, "IP/ICMP Translation Algorithm". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6145&eid=4090 -------------------------------------- Type: Technical Reported by: Fernando Gont Section: 6 Original Text ------------- 1. In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet Too Big (PTB) messages is less than 1280, change it to 1280. This is intended to cause the IPv6 host and IPv6 firewall to process the ICMP PTB message and generate subsequent packets to this destination with an IPv6 Fragment Header. Corrected Text -------------- 1. In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet Too Big (PTB) messages is less than 1280, change it to 1280. This is intended to cause the IPv6 host and IPv6 firewall to process the ICMP PTB message. Notes ----- An ICMPv6 PTB message reporting an MTU equal to 1280 does not trigger IPv6 atomic fragments. Only ICMPv6 PTB < 1280 do. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6145 (draft-ietf-behave-v6v4-xlate-23) -------------------------------------- Title : IP/ICMP Translation Algorithm Publication Date : April 2011 Author(s) : X. Li, C. Bao, F. Baker Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed Aug 20 10:57:54 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BC91A04BA for ; Wed, 20 Aug 2014 10:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ST4yQLzRlfyc for ; Wed, 20 Aug 2014 10:57:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09F01A04DC for ; Wed, 20 Aug 2014 10:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3771; q=dns/txt; s=iport; t=1408557470; x=1409767070; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fBadP2awjCoxRYPzKc6/cXq5j2uMM+dvaeVcMow21nA=; b=VOhIxKkTMs+CCgzDzy3JTooJrcTpbjSXQaa0tyokHZRcCCc7mwzFlm3o 5lTP5pS9TiRW+pvsg+XHEjwONA5QitFI+iM2T36TZobrOwe/ldVT0fS4p yY2ifJMZrpmef4p+OAalR18lwYhl1OX50B6QMDEwipQuKjGMqiyY4Vby+ M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAEjh9FOtJV2Q/2dsb2JhbAA/GoMNU1cEzEmHWQGBERZ3hAQBAQMBbgsFCwIBCEYyJQIEDgUOiCwIDTbCLReMHYMvB4MvgR0FhhGLFIIAgUqHVZUKg11sAROBNIEHAQEB X-IronPort-AV: E=Sophos;i="5.01,903,1400025600"; d="asc'?scan'208";a="70931575" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 20 Aug 2014 17:57:49 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7KHvn3n017025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Aug 2014 17:57:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 12:57:48 -0500 From: "Fred Baker (fred)" To: RFC Errata System Thread-Topic: [Technical Errata Reported] RFC6145 (4090) Thread-Index: AQHPvKBA040WgFAimkOLcvxClOnWdA== Date: Wed, 20 Aug 2014 17:57:48 +0000 Message-ID: <4F4DE3BD-A7E4-46F0-9088-BEAE54D6B5AF@cisco.com> References: <20140820164853.A041E180480@rfc-editor.org> In-Reply-To: <20140820164853.A041E180480@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_012AA932-1CA7-47CA-B4FD-EDF1F76FCEED"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/9NFXEs-wnF3w_NG_exykZFSMrpg Cc: Congxiao Bao , "behave@ietf.org" , Dave Thaler , "mls.ietf@gmail.com" , Xing Li , "spencerdawkins.ietf@gmail.com" , "Dan Wing \(dwing\)" , "fgont@si6networks.com" Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6145 (4090) 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, 20 Aug 2014 17:57:52 -0000 --Apple-Mail=_012AA932-1CA7-47CA-B4FD-EDF1F76FCEED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think I understand where Fernando is going with this. I have two = comments. (1) Considering the sentence he proposes to change to be "in error" = presumes that draft-gont-6man-deprecate-atomfrag-generation has been = ratified. It has just been posted yesterday, and has had only = preliminary mailing list discussion in 6man. I think Fernando may have a = reasonable instinct here, but is ahead of himself. I would recommend = "verifying" the erratum when the draft is approved. (2) If we're going to "correct" the text, we need to correct the text. = It is either "an ICMPv4 Packet Too Big message" (singular), in which = case the verb form is "is", or *they* are "ICMPv4 Packet Too Big = messages" (plural), in which case the verb form is is "are". Since the = RFC describes how to translate a single packet (which would be the word = RFC 2460 would prefer, not "message") from IPv4 to IPv6 or IPv6 to IPv4, = I would prefer the singular form. On Aug 20, 2014, at 9:48 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6145, > "IP/ICMP Translation Algorithm". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6145&eid=3D4090 >=20 > -------------------------------------- > Type: Technical > Reported by: Fernando Gont >=20 > Section: 6 >=20 > Original Text > ------------- > 1. In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet > Too Big (PTB) messages is less than 1280, change it to 1280. > This is intended to cause the IPv6 host and IPv6 firewall to > process the ICMP PTB message and generate subsequent packets to > this destination with an IPv6 Fragment Header. >=20 > Corrected Text > -------------- > 1. In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet > Too Big (PTB) messages is less than 1280, change it to 1280. > This is intended to cause the IPv6 host and IPv6 firewall to > process the ICMP PTB message. >=20 > Notes > ----- > An ICMPv6 PTB message reporting an MTU equal to 1280 does not trigger = IPv6 atomic fragments. Only ICMPv6 PTB < 1280 do. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6145 (draft-ietf-behave-v6v4-xlate-23) > -------------------------------------- > Title : IP/ICMP Translation Algorithm > Publication Date : April 2011 > Author(s) : X. Li, C. Bao, F. Baker > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 --Apple-Mail=_012AA932-1CA7-47CA-B4FD-EDF1F76FCEED 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 - http://gpgtools.org iD8DBQFT9OGabjEdbHIsm0MRAgOpAJ9JDg/5T/ZWUnHKFRUbBmXwkt8RZgCgjWAD PEcUUNbTqWWpRymojG6sQ1Y= =N9P0 -----END PGP SIGNATURE----- --Apple-Mail=_012AA932-1CA7-47CA-B4FD-EDF1F76FCEED-- From nobody Wed Aug 20 12:34:29 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7361A06F2 for ; Wed, 20 Aug 2014 12:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SBjRmzf5nat for ; Wed, 20 Aug 2014 12:34:25 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8F81A06E0 for ; Wed, 20 Aug 2014 12:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2322; q=dns/txt; s=iport; t=1408563264; x=1409772864; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UdKOt5MRsKrC3KBh8ewbw2SJLzUyB/jp9ZLomy6f4S0=; b=ifdKsVXt6Q11urkb6QATqKqySCk3GdPie4dKP5WvFtAFQIOG5eTtAipw m2sUdfzFumDZZyffNwxq0VROzS6n7B46dIOs9EBdSOSxp4wOYAfxN/0md hkBURugX7udBYcZG4j+B25I8VV08oyanNuqhn/6saUJbaS+J9DfLxdjJj 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAAX39FOtJV2d/2dsb2JhbABagw2BKgTUIgGBERZ3hAMBAQEDAXkFCwIBCA4KLjIlAgQOBQ6ILAjCWReMHYMvB4RMBYYRixSCAIFKh1WVCoNdbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,904,1400025600"; d="asc'?scan'208";a="70911576" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 20 Aug 2014 19:34:24 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7KJYOoc015261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Aug 2014 19:34:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 14:34:23 -0500 From: "Fred Baker (fred)" To: Fernando Gont Thread-Topic: [Technical Errata Reported] RFC6145 (4090) Thread-Index: AQHPvK2+040WgFAimkOLcvxClOnWdA== Date: Wed, 20 Aug 2014 19:34:23 +0000 Message-ID: <21E9492D-9707-4A70-BF8B-626226675FEC@cisco.com> References: <20140820164853.A041E180480@rfc-editor.org> <4F4DE3BD-A7E4-46F0-9088-BEAE54D6B5AF@cisco.com> <53F4EB0C.9030207@si6networks.com> In-Reply-To: <53F4EB0C.9030207@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_E0B3CA80-E815-42E2-82F5-30AF54F09B6A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/nOGThgHumXfrkcqmqIMHvUc_lk0 Cc: Congxiao Bao , "behave@ietf.org" , Dave Thaler , "mls.ietf@gmail.com" , Xing Li , "spencerdawkins.ietf@gmail.com" , "Dan Wing \(dwing\)" , RFC Errata System Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6145 (4090) 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, 20 Aug 2014 19:34:27 -0000 --Apple-Mail=_E0B3CA80-E815-42E2-82F5-30AF54F09B6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 20, 2014, at 11:38 AM, Fernando Gont = wrote: > Hi, Fred, >=20 > On 08/20/2014 02:57 PM, Fred Baker (fred) wrote: >> I think I understand where Fernando is going with this. I have two >> comments. >>=20 >> (1) Considering the sentence he proposes to change to be "in error" >> presumes that draft-gont-6man-deprecate-atomfrag-generation has been >> ratified.=20 >=20 > Nope. My erratum essentially notes that what RFC6145 does not comply > with RFC2460. IPv6 atomic fragments are generated in response to = ICMPv6 > PTB < 1280... *not* ICMPv6 <=3D 1280. The text in question says =93less than=94, not =93less than or equal=94. Original Text ------------- 1. In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet Too Big (PTB) messages is less than 1280, change it to 1280. ^^^^^^^^^ This is intended to cause the IPv6 host and IPv6 firewall to process the ICMP PTB message and generate subsequent packets to this destination with an IPv6 Fragment Header. If your argument is that the text should not say =93less than or equal=94,= it doesn=92t, and I would therefore recommend rejecting the erratum. > When the reported MTU is 1280, you just adapt your assumed Path-MTU > accordingly. >=20 > P.S.: If draft-gont-6man-deprecate-atomfrag-generation were published = as > an RFC, atomic fragments would *never* be generated. > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 --Apple-Mail=_E0B3CA80-E815-42E2-82F5-30AF54F09B6A 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 - http://gpgtools.org iD8DBQFT9Pg9bjEdbHIsm0MRAhp2AJ0b2hYbzCvB8vH/0jFpzAqiNn5HKQCfcitR CvQQSgntzZbEqI3uBYSdHGQ= =+YAn -----END PGP SIGNATURE----- --Apple-Mail=_E0B3CA80-E815-42E2-82F5-30AF54F09B6A-- From nobody Thu Aug 21 11:44:51 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B097F1A0668 for ; Wed, 20 Aug 2014 11:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 Bu4K_Qf-wLRu for ; Wed, 20 Aug 2014 11:42:27 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853BD1A0466 for ; Wed, 20 Aug 2014 11:42:27 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XKApy-0006qS-05; Wed, 20 Aug 2014 20:42:22 +0200 Message-ID: <53F4EB0C.9030207@si6networks.com> Date: Wed, 20 Aug 2014 15:38:04 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , RFC Errata System References: <20140820164853.A041E180480@rfc-editor.org> <4F4DE3BD-A7E4-46F0-9088-BEAE54D6B5AF@cisco.com> In-Reply-To: <4F4DE3BD-A7E4-46F0-9088-BEAE54D6B5AF@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/C71a2f1SlTiliQHeIONEmhLity4 X-Mailman-Approved-At: Thu, 21 Aug 2014 11:44:46 -0700 Cc: Congxiao Bao , "behave@ietf.org" , Dave Thaler , "mls.ietf@gmail.com" , Xing Li , "spencerdawkins.ietf@gmail.com" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6145 (4090) 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, 20 Aug 2014 18:42:30 -0000 Hi, Fred, On 08/20/2014 02:57 PM, Fred Baker (fred) wrote: > I think I understand where Fernando is going with this. I have two > comments. > > (1) Considering the sentence he proposes to change to be "in error" > presumes that draft-gont-6man-deprecate-atomfrag-generation has been > ratified. Nope. My erratum essentially notes that what RFC6145 does not comply with RFC2460. IPv6 atomic fragments are generated in response to ICMPv6 PTB < 1280... *not* ICMPv6 <= 1280. When the reported MTU is 1280, you just adapt your assumed Path-MTU accordingly. P.S.: If draft-gont-6man-deprecate-atomfrag-generation were published as an RFC, atomic fragments would *never* be generated. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Aug 21 11:44:52 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A181A0708 for ; Wed, 20 Aug 2014 13:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 OZ9cjgyV8fhj for ; Wed, 20 Aug 2014 13:01:30 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103DE1A0702 for ; Wed, 20 Aug 2014 13:01:30 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XKC4V-0007SG-VP; Wed, 20 Aug 2014 22:01:28 +0200 Message-ID: <53F4FE80.6040407@si6networks.com> Date: Wed, 20 Aug 2014 17:01:04 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20140820164853.A041E180480@rfc-editor.org> <4F4DE3BD-A7E4-46F0-9088-BEAE54D6B5AF@cisco.com> <53F4EB0C.9030207@si6networks.com> <21E9492D-9707-4A70-BF8B-626226675FEC@cisco.com> In-Reply-To: <21E9492D-9707-4A70-BF8B-626226675FEC@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/PVSin6ANs_NlB8b8SCjuM06vSzI X-Mailman-Approved-At: Thu, 21 Aug 2014 11:44:46 -0700 Cc: Congxiao Bao , "behave@ietf.org" , Dave Thaler , "mls.ietf@gmail.com" , Xing Li , "spencerdawkins.ietf@gmail.com" , "Dan Wing \(dwing\)" , RFC Errata System Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6145 (4090) 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, 20 Aug 2014 20:01:35 -0000 On 08/20/2014 04:34 PM, Fred Baker (fred) wrote: > > The text in question says “less than”, not “less than or equal”. > > Original Text > ------------- > 1. In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet > Too Big (PTB) messages is less than 1280, change it to 1280. > ^^^^^^^^^ > This is intended to cause the IPv6 host and IPv6 firewall to > process the ICMP PTB message and generate subsequent packets to > this destination with an IPv6 Fragment Header. The text says "if less than 1280, change it to 1280". Then the resulting packet will have an MTU field of 1280. The text then goes on and says "this is intended to....generate subsequent packets....with an IPv6 Fragment Header". But an ICMPv6 PTB == 1280 should not generate packets with a FH. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 26 07:19:56 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3090D1A7034 for ; Tue, 26 Aug 2014 07:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 zShWAe4CG4uD for ; Tue, 26 Aug 2014 07:19:45 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F9C1A7032 for ; Tue, 26 Aug 2014 07:19:45 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so14529639qge.39 for ; Tue, 26 Aug 2014 07:19: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 :content-type:content-transfer-encoding; bh=w7Uf+AMBBiCS5sBN2HRD2dHAiYw5rRFYQMU7A0LWSjk=; b=pCMdfh8QKOGLWrf3Xd8VTkCDukcgSp3SU28Ig+OWPp1zz2FdAJ0HBJgV3M9OZ0s+By ZnzH8pgrvYn2GKKJdfWGu+/a0NMk7+e5pu+DSmLjaixZrfm8wf0HoHKyx/Xs7RPBcLTB hhtuehH/R4BCz4uv948SoAE10f5l0OUFZxDN2YgSjYRs29mt7FOizz/Yi0/Yq/kbl2If yheRGVLiRF9pEybzbBc5DK2oo90LqF9W2pI4J2L9Ec0nnyv1efnE8MLUHCm8sSM2d7+s TZwF5e8wLVUSx5L5/2XKqUjSQJLLGA4Naeo/TrUxDLO4NnrWHIu3jo4p1I9+UIHsHffM rcZQ== X-Received: by 10.140.101.86 with SMTP id t80mr43516366qge.91.1409062784810; Tue, 26 Aug 2014 07:19:44 -0700 (PDT) Received: from [192.168.97.118] ([67.210.160.130]) by mx.google.com with ESMTPSA id o6sm9844796qag.40.2014.08.26.07.19.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 07:19:44 -0700 (PDT) Message-ID: <53FC9781.9020609@gmail.com> Date: Tue, 26 Aug 2014 10:19:45 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/5lZ0AicAYibyjnoCDIlb7JZ4vxQ Cc: Simon Perreault , Tina TSOU Subject: [BEHAVE] Issue tracking for NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 14:19:51 -0000 The NAT MIB document, draft-ietf-behave-nat-mib-11, is going through the process of review as an AD-sponsored document. David Harrington had a long list of issues. I am posting his E-mail here before breaking these issues down and putting them into an issue tracker so that I have a message reference for each issue. I will let you know the details for reaching the tracker when it is ready. I'm creating it directly in the Behave Wiki rather than using TRAC. Tom Taylor > -----Original Message----- From: David Harrington > [mailto:dbharrington@comcast.net ] > Sent: Tuesday, June 17, 2014 2:22 AM To: > draft-ietf-behave-nat-mib@tools.ietf.org > Cc: behave-chairs@ietf.org ; behave-ads@ietf.org > Subject: MIB Doctor review of draft-ietf-behave-nat-mib-11 > > Hi, > > I have done a MIB Doctor review of draft-ietf-behave-nat-mib-11. I > have reviewed this document as part of the MIB Doctor directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > operational area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > My impression is that this document is not ready for publication. > > Technical issues: The nature of the realm usage in NAT-MIB could have > serious consequences to existing deployments of other MIB modules. > The use of calculated thresholds, and calculated values to compare > to thresholds, could be problematic, especially to > resource-constrained agent implementations. > > Editorial issues: A significant cause for concern is the naming, > which doesn't follow RFC 4181 > guidelines. This will make the MIB harder for operators to use in > the field. > Another significant concern is the lack of REFERENCE clauses. This > will make > the MIB harder for operators to use in the field. The description > clauses are sometimes rather sparse. This will make the MIB > harder for operators to use in the field. Some of the descriptions in > the module are sparse, while the surrounding text contains a better > description. But MIB modules are frequently distributed without the > surrounding RFC text. This will make the MIB harder > for operators to use in the field. The IMPORTS clauses don't identify > the RFC that contains the MIB module being imported from. This will > make the MIB harder for operators to use in the field. The > redefinition of realm in the middle of a bis could be a problem, > especially for managers. This will make the MIB harder for operators > to use > in the field. > > > Detailed review: > > 1) We have discussed whether the new objects really should be a new > MIB module, published under a new MIB module name. Reading through > this document, I feel that deprecating the whole previous NAT-MIB > within the same document is a mistake. It makes the document harder > to deal with. This really should be two separate documents and two > separate MIBs - with different module names. > > The current approach might be perfectly viable for an agent implementation, > where the NAT-MIB is likely to be an implementation of EITHER the > first half > of this document, or the second half of this document. But it seems > problematic for an NMS implementation that has to support BOTH > implementations based on RFC4008, and implementations based on this > document. I especially think about the fact that NMSs import MIB > modules, including the Description clauses for the managed objects, > and can display the description clauses so operators can see what the > definition of the object is. With this document, NMS applications > MUST parse all the deprecated objects, even if, at some future time, > there are no devices that implement the RFC4008 NAT-MIB. If the > deprecation was handled in a separate RFC from the new MIB module, > and an NMS no longer had to support the "old" NAT-MIB, then NMSs in > the future would only need to import the new document. > > I found it especially irritating to review, because I am used to > finding Textual Conventions at the beginning of the MIB module, which > is usually at > the beginning of the document containing the MIB module, but here, I > had to look for the T-Cs in the middle of a long MIB module, because > I had to work > past the first 54 pages of deprecations to find the T-Cs of the new module. > Every user of this MIB document will be similarly inconvenienced, > over and over. > > 2) This new I-D is redefining a term "realm" that is defined in the original > NAT-MIB. (see section 3.3). RFC4008 defined realm objects to be of > type INTEGER, but the new NAT-MIB defines realm objects as > SnmpAdminStrings. An NMS (and operators) needs to be able to support > devices that implement the "old" NAT-MIB and devices that implement > the "new" NAT-MIB. With this new NAT-MIB, an NMS user must be aware > when they look at the description of a realm-related object, whether > that object was defined in the RFC4008 NAT-MIB or in the > NAT-MIB, in order to understand which meaning and datatype of the > term "realm" applies. But since RFC4008 is updated by being > deprecated in the same document, in the same-named MIB module, the > reader of the new NAT-MIB must determine whether the object was > defined in the first half of this document, i.e., the > first half of the NAT-MIB, i.e., the "old" deprecated NAT-MIB, or in > the second half of this document, to understand the meaning of the > word realm. I think this is problematic. > > 3) Section 3.3 explains that implementations of MIB modules that implicitly > support realms (e.g.,OSPFv2-MIB), and utilize SNMPv3 contexts (or > presumably communities in community-based SNMP) in an SNMP-standard > compliant manner, will no longer be able to do things in those > standard-compliant manners, because the NAT-MIB design spans realms. > > This I-D should list the names and references for the "many MIBs" > that "implicitly support realms in one form or another" that may be > broken by this NAT-MIB's usage of realm. I suggest an "Operational > Considerations" section for this information. I think the IETF > community needs to better understand this claim before approving this > document. > > 4) I will assume all the RFC4008 objects that are being deprecated > have been > included here, and each has had its status changed to deprecated. I > have not > gone through the document looking at each and every deprecation. > > 5) ProtocolNumber is a rather generic name for this textual > convention. It doesn't start with "nat". I fear there is a potential > for conflict. This does not follow the conventions recommended in > RFC4181 Appendix C: - Names of TCs that are specific to the MIB > module and names of SEQUENCE types that are used in conceptual table > definitions should start with a prefix Xxx that is the same as xxx > but with the initial letter changed to uppercase. OPT-IF-MIB uses > the prefix OptIf on the names of TCs and SEQUENCE types. > > 6) ProtocolNumber is dependent on an IANA registry. There should be a > REFERENCE clause with a link to the specific IANA registry, so > implementers/users can see the list of valid values. > > 7) This document does not provide REFERENCE clauses; it really > should. > > 8) natPoolID - the description does not describe what a pool is, or provide > a REFERENCE clause. > > 9) natBehaviorType has only a reference in the description. In > general it is > better to actually have a description in the description clause and provide > the reference in the REFERENCE clause. This is not merely an academic > nit. Because GUI-based NMSs frequently display the Description clause > in a window so the user can understand the meaning of the object, it > is important that the description actually explain the meaning. > Providing a reference in the description implies that the user would > then need to go find the RFC and find the section of the RFC, and > read the whole section to understand what this object means. Not very > helpful. On top of that, an NMS might know how to track down an RFC > and provide a link to the document in the REFERENCE clause, but it > wouldn't necessarily know to parse the Description clause to find the > reference. > > 10) NatPoolingType is only used to define the type of one object. The > description clause in the object is indirect - " "Type of address > pooling behavior that was used to create this mapping." To understand > this object, you need to look at the textual convention. But the > textual convention is also indirect - "Pooling type as described in > [RFC4787] sections 4.1." Even looking at RFC4787 section 4.1 isn't > immediately helpful, because the discussion of arbitrary versus > paired is a subset of section 4.1 (that is not called out as a > subsection); it is found in the one-paragraph explanatory text for > REQ-2. A short description in the OBJECT description clause could be > made from a couple sentences from section 4.1, supplemented with a > REFRERENCE clause, which would be much easier for users than the > current indirect-indirect-someplace-in-this-text approach. > > 11) SubscriberIdentifierType concerns me. We are supposed to be > standardizing things here. But this appears to be a standardized > "bucket" which implementers can stuff with their own proprietary > identifiers, especially the "other" value. How is a vendor-neutral > NMS supposed to know how to handle the "other" value? I feel > uncomfortable with this whole identifierType, which implies that an > implementation needs to go parse the packet to pull out additional > information to identify the subscriber, without standardizing how > this information should be extracted from the message in a > standardized vendor-neutral manner. > > I feel uncomfortable that for the "other" type, each implementation defines > the semantics of AND and OR combinations. How should a > vendor-neutral NMS handle the implementation-specific variations; > where is the AND/OR semantic decision documented by each implementer, > to make this vendor- interoperable? > > For the interfaces choice, how is the set of interface indexes constructed? > I'm confused by this. The classifying information is in the packet (identify > the subscriber from an incoming packet); so does the packet contain a > set of > interface indexes that the receiving implementation is supposed to extract? > There is no reference to the type of packet involved, and I haven't > had to unpack a set of interface indices from a packet before. What > type of packet > contains a set of one or more ifIndexes? The RFC2863 textual > convention doesn't seem to describe this. > > 12) SubsInterfaceIdRowIndex - unique within what scope? Within the > agent? > > 13) I am concerned about abbreviations is naming. RFC4181 Appendix C > suggests - When abbreviations are used, then they should be used > consistently. Inconsistent usage such as > > xxxYyyDestAddr xxxZzzDstAddr > > should be avoided. > > But sometimes, object names in this module use Identifier and other > times ID: natSubscriberVpnIdentifier vs. natSubscriberIPEncapsIdType > Sometimes it's subscriber, other times it's "subs". > natSubscriberVpnIdentifier vs. natSubsInterfaceIndex Sometimes it's > threshold, sometimes it's "thresh": natMappingsNotifyThreshold vs. > natSubscriberMapNotifyThresh For an operator, especially one under > stress, using a command-line SNMP tools to query a value, it is > really irritating to have some objects abbreviated one way and other > objects abbreviated other ways. > > 14) This is made worse by inconsistent name construction, such as a > set of nat limits being named nat + "Limit" + , as in > natLimitMappings but the set of notify thresholds are constructed as > nat + + "NotifyThreshold", as in > natMappingsNotifyThreshold. So operators need to recall which way you > chose to construct the names, on a case-by-case basis, > because you are not being consistent. Why not do nat + + "Limit" > to match the way you construct NotifyThreshold names, or use > nat+"NotifyThreshold"+ to match how you construct the > Limit names? > > 15) Once again, I will point out consistency in naming, following > Appendix C > conventions: " - The descriptor associated with a conceptual table > should be of the form xxxZzzTable; the descriptor associated with the > corresponding conceptual row should be of the form xxxZzzEntry; the > name of the associated SEQUENCE type should be of the form > XxxZzzEntry; and the descriptors associated with the subordinate > columnar objects should be of the form xxxZzzSomeotherName. An > example from the OPT-IF-MIB is the OTMn table. The descriptor of the > table object is optIfOTMnTable, the descriptor of the row object is > optIfOTMnEntry, the name of the associated SEQUENCE type is > OptIfOTMnEntry, and the descriptors of the columnar objects are > optIfOTMnOrder, optIfOTMnReduced, optIfOTMnBitRates, > optIfOTMnInterfaceType, optIfOTMnTcmMax, and optIfOTMnOpticalReach." > > But we find in this NAT-MIB module inconsistency: natCountersTable > OBJECT-TYPE ... natCountersEntry OBJECT-TYPE ... NatCountersEntry > ::= SEQUENCE { natTranslations Counter64, > natOutOfPortErrors Counter64, natResourceErrors > Counter64, natQuotaDrops Counter64, natMappingCreations > Counter64, natMappingRemovals Counter64, > natAddressMappingCreations Counter64, natAddressMappingRemovals > Counter64 } > > And natLimitsTable OBJECT-TYPE ... natLimitsEntry OBJECT-TYPE ... > NatLimitsEntry ::= SEQUENCE { natLimitMappings > Unsigned32, natMappingsNotifyThreshold Unsigned32, > natLimitAddressMappings Unsigned32, natAddrMapNotifyThreshold > Unsigned32, natLimitFragments Unsigned32, > natLimitSubscribers Unsigned32 } (notice Limits vs Limit, as > well as objects with no natLimit prefix, as well > as "AddressMappings" vs "AddrMap".) > > 16) If there is a concern that descriptor length can become > problematic, "Threshold" is never used without the "Notify" prefix. > You could probably shorten the NotifyThreshold names to just use > Threshold. > > 17) Consistency. Watermark vs Threshold. > > 18) natLimitMappings - this is in a table of limits for a NAT > instance. What does "Global" mean in this context? See others in this > table as well. > > 19) natMappingsNotifyThreshold - the description is "See > natNotifMappings." Which says "This notification is generated when > the number of active mappings exceeds the value of > natMappingsNotifyThreshold." Why not write the (modified) description > into both places rather than using > indirection? > > 20) natNotifMappings Typically we try to not derive values when > defining objects. For example, RFC4188 states as a principle " > Exclude objects that are simply derivable from others in this or > other MIB modules." But natNotifMappings is triggered when " the > number of active mappings exceeds the value of > natMappingsNotifyThreshold" But we don't actually track active > mappings; we track creations and removals, and we calculate active by > subtracting removals from creations (active=creations-removals). If > you want to use active against the threshold, why not simply track active > and skip tracking creations and removals? > > Is there a reason to track creations and removals? If the maximum > number of creations performed is important (maybe for memory > management or something?), then why not track creations and active > and let somebody else calculate the removals > (removals=creations-active) If the number of removals is important (I > have no idea why), then you can track active and removals, and let > somebody else calculate (creations=active+removals) This way a > notification doesn't have to wait to calculate active. > > 21) natNotifMappings - the relationship between the notification and > thresholds is clear. The relationship to "which mappings" is a bit > less clear. I see a natMapIntAddrTable, and a natMappingTable; which > one is related to natNotifMappings? (and is the savings from dropping > the y from notify significant?) > > I assume the fact we are sending a notification means it is important > for the operator to know right away when "active exceeds threshold" > happens. I have to guess that this might be related to > memory/resource management. But I have to guess because nothing is > said about why these particular values are tracked. Nothing is said > about table row re-use when a mapping is removed. Is it really > important to know the creation and removal counts, rather than > just the active count? Is it important to not reuse an index value to > make sure that the NMS doesn't associate previously acquired data > with a new mapping. (This is important, for example, if ifIndex > changes during a reboot, because > an NMS could take data associated with an old ifIndex and confuse it > as being associated with a new ifIndex, and totally misinterpret > trends, and so > on. Other MIB modules need to protect against reuse of an index > value, at least for some period of time, or until rollover.) > > 22) It's a good thing the description of natPoolTable is "Table of > pools" because I might have confused it as being something else. > 8-ball anyone? Description please? > > 23) natpoolRealm - "Realm to which this pool's addresses belong." MIB > modules are often distributed without the surrounding text from the > RFC. > > So it is important to be sure the description is meaningful without > the whole RFC being present. At a minimum, especially since you are > defining realm in this document, you > should provide a REFERENCE to the text in this RFC that contains the > definition for realm. > > 24) natNotifPoolWatermarkLow and WatermarkHigh > > we usually try to not use derived values in MIB modules. We try to > keep the > agent simple, and push complexity toward the NMS, which normally has > far more resources available. When you set a watermark/threshold as a > percentage, then the system needs to use CPU cycles to calculate the > percentage - CPU cycles that might be better > used forwarding packets. > > The calculations you expect are rather complex - you require summing > (allocations - deallocations) over all address ranges, then dividing > by the > total number of ip addresses in the poll and by the size of the port > range (calculated by portmax-portmin+1). > > I'm not sure that that formula is unambiguous; is that > (sum(allocations-deallocation)/ipaddresses)/portrange or am I > calculating something with (ip addresses and size of portrange) > before dividing? Can you > use parentheses or something? > > How often should this complex calculation be done to monitor the > percentage versus the threshold? Should this be re-calculated > ***every time*** one of the following changes: allocation or > deallocation across any address range, > total number of ip addresses, or size of the port range? (and of > course, the > watermark setting). > > Wow! That seems like a lot of CPU cycles. > > 25) natpoolIndex - the description doesn't mention the scope of uniqueness. > Is this unique across all address pools in all instances? Unique > within a nat instance, but not necessarily across other nat > instances? > > 26) natPool watermarks There is mention of low usage mode and high > usage mode. Is there a REFERENCE you can make, maybe to NAT > requirements or something, that explains this a bit more? Is there a > reason why BEHAVE is not trying to standardize low/high usage > behaviors? (isn't standardizing behaviors what behave is all about?) > > Are the "may" terms here RFC2119-compliant? Usually RFC2119 "may" > terms are capitalized. > > 27) It is very helpful to add comments to your IMPORTS identifying > the RFC that contains the MIB you are importing from. > > 28) natPoolRangeType - can this support any of the address types > allowed by > this textual convention? Or should the text constrain the acceptable values? > I'm not sure which ways to limit this are acceptable. Let me know if > all the > address types cannot be supported, and I'll check with other mib > doctors to > determine the best way to constrain it. > > 29) natMappingTable - "Table of mappings indexed by external > 3-tuple." I'm not sure this is accurate, given INDEX { > natInstanceIndex, natMappingProto, natMappingExtRealm, > natMappingExtAddressType, natMappingExtAddress, natMappingExtPort } > > 30) natMappingExtAddress - can you point me to the REFERENCE for > "the undefined address"? I didn't find it in RFC4001. Ditto for > natMappingIntAddress > > 31) natMappingMapBehavior and natMappingFilterBehavior - for reasons > mentioned above, please include a description, not just a reference > in the description text. Put the reference in a REFERENCE clause. > > 32) natMappingSubsIndex - you don't really need the Index suffix. > This would be more meaningful as natMappingSubscriber > > 33) natSubscribersTable, natSubscribersEntry, and natSubscriberIndex > (et al) > are not consistent. I recommend losing the plural. > > 34) do the existence of fields natSubscriberVlanIdentifier, > natSubscriberVpnIdentifier, natSubscriberIPEncapsIdType, and > natSubscriberIPEncapsIdAddr depend on the value of > natSubscriberIdentifierType? If so, then it might be better to define > this as a sparse augments table. Let me know, and I'll check with the > MIB Doctors > list about the best way to do this. > > 35) natSubscriberIdentifierType - " Unused identifier values MUST be > zero or > equivalent". I think this is under-specified. I think the > zero-equivalents should be specified here for each type. When the > type is none(0), and the identifier is "none", does this mean the > identifier field is not implemented, or has a zero value or empty > string or > what? Which of these is the zero equivalent? The TC > SubscriberIdentifierType says the interfaces(1) type means the > identifier is a set of **one or more** interface indexes. What is > the zero-equivalent of a set of one or more interface indexes? > VPNIdorZero says " The semantics of the value zero-length > OCTET STRING are object-specific and must therefore be defined as > part of the description of any object that uses this syntax." So > presumably, the zero equivalent is a zero-length OCTET STRING. But > the description here does not define the semantics of the zero-length > string; it > only implies the semantics. And for other(5), we have no idea what a > zero-equivalent is. > > 36) natSubscriberIntPrefixType is a "Subscriber's internal prefix > type." While the corresponding address is a "Prefix assigned to a > subscriber's CPE." I tend to think of a CPE as being the border > between a subscriber's network > and an ISP's network. If the subscriber entry represents a host > served by a managed enterprise NAT, is this still the prefix type for > the CPE? Please clarify if the type is the internal prefix type for > the subscriber's > CPE, or simply the subscriber's internal prefix type. > > 37) natSubscriberLimitMappings - again, we should avoid calculated objects. > This depends on "active" mappings, which is a calculated value. > > 38) natSubscriberMapNotifyThresh - consistency in naming please; > this seems to be a real problem throughout the subscriber table. > (natSubscribers vs natSubscriber, thresh, mappngs vs Map) > > 39) natSubscriberIPEncapsIdType - I find the "when not unknown(0)" > to be an odd description. The InetAddressType description is " A > value that represents a type of Internet address." I think that > should suffice here as > well, even though unknown(0) has special semantics described in the > T-C. > > 40) natSubsInterfaceIdentifierTable - the description contains a > sentence fragment; I don't know what it means - " 'OR' semantics if > multiple interface indexes are present." I find the other sentences a > bit short; I recommend rewriting the description to make it clearer. > > 41) natSubsInterfaceIdSubsIndex - I have some concerns about the use > of Index as parts of object descriptors and part of object > descriptions, for objects that are not INDEXes, when INDEX is a SMI > reserved word (RFC2578, section 3.7). I don't find the "Index" > suffix necessary. I think SubscriberIndex would be fine as > Subscriber, and SubsInterfaceIdRowIndex would be fine as > SubsInterfaceIdRow, and natSubsInterfaceIdRowIndex would be fine as > natSubsInterfaceIdRow, etc. > > 42) natSubsInterfaceIdRowIndex - the description is "Row index." > There is no description of why this is being defined, or what it is > expected to be used for. The T-C has a better explanation of its > uniqueness and its assignment to rows, but no description of why it > is needed. It might have been better explained in the > natSubsInterfaceIdentifierEntry description, where it is used in the > INDEX. But I don't understand the description there - "Each entry > provides a single interface index." Can you provide an example of how > this table works? > > 43) I am a bit concerned about the compliance options. If we are > standardizing behaviors, why do we have five compliance levels? Lots > of compliance levels = lack of standardization. > > --- Security considerations --- 44) What objects reveal host > identities? Do you mean host addresses? I think the community has > made a statement about identity versus address in efforts like HIP > and SNMPv3. 45) If a disgruntled former employee can break into > private hosts, can attackers who never worked for the employer do so > as well? I don't have any > employees, and no former employees; does that mean this is an attack > vector I can totally ignore? > > > Hope this helps, > > David Harrington dbharrington@comcast.net > +1-603-828-1401