Skip to main content

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

Yes

(Allison Mankin)
(Jon Peterson)

No Objection

(Alex Zinin)
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
(Scott Hollenbeck)
(Ted Hardie)
(Thomas Narten)

Note: This ballot was opened for revision 09 and is now closed.

Allison Mankin Former IESG member
Yes
Yes () Unknown

                            
Bert Wijnen Former IESG member
Yes
Yes (2004-06-09) Unknown
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.
Jon Peterson Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2004-06-09) Unknown
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.
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2004-06-08) Unknown
  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.
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Steven Bellovin Former IESG member
No Objection
No Objection (2004-06-08) Unknown
There are TCP- and UDP-specific entries.  Should there be SCTP-specific entries?
Ted Hardie Former IESG member
No Objection
No Objection () Unknown

                            
Thomas Narten Former IESG member
No Objection
No Objection () Unknown