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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
