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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
