Re: [Gen-art] Gen-ART Last Call review of draft-perrault-behave-natv2-mib-03.txt

Tom Taylor <> Fri, 15 May 2015 20:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B10B51A1B51; Fri, 15 May 2015 13:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4cGfTy_gPZkm; Fri, 15 May 2015 13:03:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE88F1A1B2C; Fri, 15 May 2015 13:03:32 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so4021588igb.1; Fri, 15 May 2015 13:03:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=2qN+YPbWOtBAsaRMuvckBukEUw/bzMzxvsF+GbL83hw=; b=uwu1dkRhbQn6xjzuV4JpaJsdiNDQC8HuvzFh+jcmkar6tywXbrpFSMrlMJPD8Cwn5H cQSpEEyCVyqbTSupI89OSAHb1pJdwGzgFBX9cAVXyurOeIqKwtLo+qrs5VYGoYfoJw15 0VMdi4yV8oMky+FZp9iNd8z6TzPU76CFJURjRVM17SPxIHZUTuUiuJvMUbUwhB/VdbjG CiHxnyt0eV4vNJ4CpaZ55jfK5bR2WQXremLanDfjR9FLEEz4yQDYkecUOd/IpqPqGL9r G4eLtzlSCOsUbdeANk18ZU+w/6hD914+K2PhLttwrwXcQMhczvAMIocblTIM/C+3qTmG VIEQ==
X-Received: by with SMTP id c20mr461537igo.0.1431720212177; Fri, 15 May 2015 13:03:32 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id fs5sm170458igb.0.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2015 13:03:31 -0700 (PDT)
Message-ID: <>
Date: Fri, 15 May 2015 16:03:31 -0400
From: Tom Taylor <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Suresh Krishnan <>, "" <>, General Area Review Team <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-perrault-behave-natv2-mib-03.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 May 2015 20:03:51 -0000

Thank you for your reviews of this and the deprecation document. 
Responses below.

Tom Taylor

On 30/04/2015 12:04 AM, Suresh Krishnan wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <>.
> Please resolve these comments along with any other Last Call comments
> you may receive.
> Document: draft-perrault-behave-natv2-mib-03.txt
> Reviewer: Suresh Krishnan
> Review Date: 2015-04-29
> IETF LC End Date: 2015-04-29
> Summary: There are some minor issues in the draft that need to be fixed
> before publication as a Proposed Standard.
> * Some objects and the their textual conventions vary only by case.
> There are three such instances
> natv2SubscriberIndex and Natv2SubscriberIndex
> natv2InstanceIndex and Natv2InstanceIndex
> natv2PoolIndex and Natv2PoolIndex
[PTT] I found precedents (e.g., charPortEntry, SYNTAX CharPortEntry) in 
the second MIB I looked in, RFC 1658. I'm sure there are lots more. 
Unless current practice dictates otherwise, I'd prefer to leave them.

> * The natv2PoolRangeBegin and natv2PoolRangeEnd do not have an
> immediately preceding InetAddressType object as required by RFC4001.
[PTT] RFC 4001 does not precisely require this. What it requires is that 
the type be specified, preferably registered before the actual address, 
and conformity to that type be checked.

[PTT] In the present case the comments to the address objects concerned 
point to the type, which happens to be in the parent table rather than 
the natv2PoolRangeTable expansion of the parent table. This is to 
enforce the constraint that all addresses assigned to a given address 
pool must be of the same type. I could add MUSTs to the comments to 
emphasize this, if you think it desirable.

[PTT] The alternative would be to put the address type into the 
natv2PoolRangeTable as you suggest. However, then we would still need to 
enforce the logical constraint that all addresses assigned to the same 
address pool must be the same type by means of comments. The current 
arrangement is more elegant.

> Thanks
> Suresh