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

Thanks for your careful review, Suresh.

I have noted the comments and Tom’s responses; I think we’ll leave the rest to him to see if he wants to make further changes.

Jari

On 15 May 2015, at 23:03, Tom Taylor <tom.taylor.stds@gmail.com> wrote:

> 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
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Attachment: signature.asc