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