Definitions of Managed Objects for Network Address Translators (NAT)
draft-ietf-nat-natmib-09

Sent mail to authors asking for text for RFC Editor Notes for
Bert's warnings and the address domain definition - Suresh will
give by the weekend.

[Note]: 'Had careful MIB doctor review.  Wrt function, allowed to configure
only the NAT''s address range and not NAT/firewall binds or
firewall policies.  This means no conflict with MIDCOM.' added by Amy Vezza

[Ballot comment]
Reviewed by Brian Carpenter, Gen-ART

His main comments:
Discuss 1:  Should we put a NAT-related document on the standards
track (regardless of the technical quality of the document)?

If published as PS, this document will allow vendors to refer to
"IETF standards compliant NAT" quite legitimately. Do we really want
to do that? Please also consider publishing this as Informational,
like a vendor MIB.

As to technical quality, I assume this has been reviewed by a MIB
doctor; I'm not competent for that. But in general the document seems
clear and competent and makes sense in terms of the things NATs
have to do.

However, I have one big concern. You won't hear this often from me,
but I have a problem with the fact that this MIB is defined
to work equally well for IPv4 and IPv6, by using InetAddressType
consistently. But the whole point of IPv6 is to avoid the need
for NAT. We might need a MIB that works for NAT-PT. But there is
no reference to NAT-PT (RFC 2766).

Discuss 2: why do we need a MIB that works for IPv6 NAT, unless
it is for NAT-PT?

However, I do not agree with his Discuss 1 (NATs are a fact of life in IPv4, and we should deal with them competently), and don't think that Discuss 2 is enough reason to hold up the document.

Other ADs may think differently.

[Ballot comment]
I see:
  natMIB MODULE-IDENTITY
    LAST-UPDATED "200404180000Z"
    ORGANIZATION "Individuals"
I can live with that, but would it not be better to have something
like
  natMIB MODULE-IDENTITY
    LAST-UPDATED "200404180000Z"
    ORGANIZATION "IETF Transport Area"
or
    ORGANIZATION "IETF Individuals"

after all, we approve it as IETF for PS, don't we.
It can of course not be a WG, because it is not a WG doc.
I am not hung up on it.

smicng gives:

  W: f(nat.mi2), (897,1) Row "natAddrBindEntry" has indexing that may
    create variables with more than 128 sub-ids

This one needs a warning to explain that implementers must be
carefull to not exceed the 128 sub-id limit. That warning is present
in the DESCRIPTION clause of: natAddrBindLocalAddr
It would be better to move that warning into the DESCRPTION clause of
natAddrBindEntry (at least that is where we normally put it).
I can live with it though.

  W: f(nat.mi2), (1123,1) Row "natAddrPortBindEntry" has indexing that
    may create variables with more than 128 sub-ids

This one needs a warning to explain that implementers must be
carefull to not exceed the 128 sub-id limit. That warning is present
in the DESCRIPTION clause of: natAddrPortBindLocalAddr
It would be better to move that warning into the DESCRPTION clause of
natAddrPortBindEntry (at least that is where we normally put it).
I can live with it though.


They have:
  natMIBConformance OBJECT IDENTIFIER ::= { natMIB 2 }

  natMIBGroups      OBJECT IDENTIFIER ::= { natMIBConformance 1 }
  natMIBCompliances OBJECT IDENTIFIER ::= { natMIBConformance 2 }

Where as the recommended assignments are:
  natMIBConformance OBJECT IDENTIFIER ::= { natMIB 2 }

  natMIBCompliances OBJECT IDENTIFIER ::= { natMIBConformance 1 }
  natMIBGroups      OBJECT IDENTIFIER ::= { natMIBConformance 2 }

I.e., first the Compliances, then the Groups.
I can live with it, but for consistency in MIB modules it would be better
to follow the recommendation.

[Ballot comment]
The concept of an addressing realm is important to understanding this
  document and NAT in general.  It would help the reader if this was
  explained in the terminology section.

  Delete section 7 prior to publication.

[Note]: 'Had careful MIB doctor review.  Wrt function, allowed to configure
only the NAT''s address range and not NAT/firewall binds or
firewall policies.  This means no conflict with MIDCOM.' added by Allison Mankin

[Note]: 'Had careful MIB doctor review.  Wrt function, allowed to configure
only the NAT''s address range and not NAT/firewall binds or
firewall policies.  This means no conflict with MIDCOM.' added by Allison Mankin

[Note]: 'Significant revs for 09 included: only range of addresses is writable; it is clearly stated that configuration and
monitoring covers only NAT functions, not any ancillary firewall policy functions.? A re-review for MIB checking
is being done before IETF LC for PS (as an indiv. subm).' added by Jon Peterson

[Note]: 'Significant revs for 09 included: only range of addresses is writable; it is clearly stated that configuration and
monitoring covers only NAT functions, not any ancillary firewall policy functions.  A re-review for MIB checking
is being done before IETF LC for PS (as an indiv. subm).' added by Michelle Cotton

IANA Last Call Comments:
Upon approval of this document, the IANA will assign a
mib-2 number to natMIB.  We understand this to be the
only IANA Action.

[Note]: 'Significant revs for 09 included: only range of addresses is writable; it is clearly stated that configuration and
monitoring covers only NAT functions, not any ancillary firewall policy functions.   A re-review for MIB checking
is being done before IETF LC for PS (as an indiv. subm).' added by Allison Mankin

[Note]: 'Significant revs for 09 included: only range of addresses
is writable; it is clearly stated that configuration and
monitoring covers only NAT functions, not any ancillary
firewall policy functions.
functions' added by Allison Mankin

[Note]: 'Expert Review by Bert Wijnen''s MIB Doctor has been completed at the end of Jan 2004.  Next it to present the case for Informational RFC with a limited scope title.' added by Allison Mankin

2002-09-03 - resent bert&#145s comments to author
output of smilint -l 9 follows,
empty output means everything is fine.
--start--
864: warning: index of row `natAddrBindEntry&#145 can exceed OID size limit by 141 subidentifier(s)
1056: warning: index of row `natAddrPortBindEntry&#145 can exceed OID size limit by 143 subidentifier(s)
1022: warning: node `natAddrBindStatus&#145 must be contained in at least one conformance group
1257: warning: node `natAddrPortBindStatus&#145 must be contained in at least one conformance group
1952: warning: current group `natStatsGroup&#145 is unconditionally optional
1987: warning: current group `natMIBNotifConfigGroup&#145 is unconditionally optional
1996: warning: current group `natMIBNotificationObjectsGroup&#145 is unconditionally
optional
2006: warning: current group `natMIBNotificationGroup&#145 is unconditionally optional

State Changes to Expert Review                                    from Pre AD Evaluation                                by Scott Bradner