[ipcdn] RE: Protocol Action: 'Definitions of Managed Objects for Network Address Translators (NAT)' to Proposed Standard
"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Wed, 01 September 2004 22:15 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11198 for <ipcdn-archive@ietf.org>; Wed, 1 Sep 2004 18:15:44 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2dQe-0007OW-TU for ipcdn-archive@ietf.org; Wed, 01 Sep 2004 18:18:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2d8n-0001Qf-PS; Wed, 01 Sep 2004 17:59:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2cSe-0003ac-V3 for ipcdn@megatron.ietf.org; Wed, 01 Sep 2004 17:16:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05025 for <ipcdn@ietf.org>; Wed, 1 Sep 2004 17:16:05 -0400 (EDT)
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2cUu-0001xn-QU for ipcdn@ietf.org; Wed, 01 Sep 2004 17:18:29 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i81LFYVH015150 for <ipcdn@ietf.org>; Wed, 1 Sep 2004 16:15:35 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <RLRJ66YC>; Wed, 1 Sep 2004 23:15:34 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550516F67D@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Jean-Francois Mule <jf.mule@cablelabs.com>, ipcdn@ietf.org
Date: Wed, 01 Sep 2004 23:15:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a
Cc: bwijnen@lucent.com, Allison Mankin <mankin@isi.edu>
Subject: [ipcdn] RE: Protocol Action: 'Definitions of Managed Objects for Network Address Translators (NAT)' to Proposed Standard
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094
jean Francois writes:
>
> Folks,
>
> Does this MIB for NAT devices Internet-Draft have any implications on
> the ipcdn CableHome MIBs? do we need some time to do a final review of
> this ID? If you have any comments, please send them asap (it may be too
> late... but I want to make sure the group has seen this protocol action
> notice).
>
It would indeed be REALLY late. Went through a 4 week IETF Last Call quite
a while back. But if you find any fatal flaws, we certainly want to hear
about them.
Bert
> Jean-Francois.
>
> -----Original Message-----
> From: The IESG [mailto:iesg-secretary@ietf.org]
> Sent: Friday, August 27, 2004 3:20 PM
> To: IETF-Announce
> Cc: Internet Architecture Board; RFC Editor
> Subject: Protocol Action: 'Definitions of Managed Objects for Network
> Address Translators (NAT)' to Proposed Standard
>
>
> The IESG has approved the following document:
>
> - 'Definitions of Managed Objects for Network Address
> Translators (NAT)
> '
> <draft-ietf-nat-natmib-09.txt> as a Proposed Standard
>
> This document has been reviewed in the IETF but is not the
> product of an
> IETF Working Group.
>
> The IESG contact person is Allison Mankin.
>
> Technical Summary
>
> This document defines a portion of the Management Information
> Base (MIB)
> for
> devices implementing Network Address Translator (NAT)
> function. This MIB
>
> module may be used for configuration of specific aspects of the NAT
> function (but in particular, not to configure NAT bindings). Firewall
> configuration, in a NAT-firewall-combining device, is specifically
> outside the scope of this
> document.
>
> Working Group Summary
>
> Although this document is an individual submission (developed largely
> after
> closure of IETF's NAT working group, it was reviewed by the MIDCOM
> working group. A good number of comments were received from MIDCOM
> participants.
>
> Protocol Quality
>
> This specification was reviewed for the IESG by Allison Mankin, Bert
> Wijnen,
> and Juergen Schoenwaelder, of the MIB Doctors.
>
> RFC Editor Notes
>
> Section 3. Terminology
>
> OLD:
>
>
> Definitions for majority of the terms used throughout the document
> may be found in RFC 2663 [RFC2663]. Additional terms that further
> classify NAPT implementations are defined in RFC 3489 [RFC3489].
> Listed below are terms used in this document
>
> NEW:
>
>
> Definitions for majority of the terms used throughout the document
> may be found in RFC 2663 [RFC2663]. Additional terms that further
> classify NAPT implementations are defined in RFC 3489 [RFC3489].
> Listed below are terms used in this document
>
> Address realm - An address realm is a realm of unique network
> addresses that are routable within the realm. For example, an
> enterprise address realm could be constituted of private IP
> addresses in the ranges specified in RFC 1918 [RFC1918], which
> are routable within the enterprise, but not across the Internet.
> A public realm is constituted of globally unique network
> addresses.
>
> [And add RFC 1918 to the Informative References]
>
> -----------
>
> OLD:
>
> NAT Session - A NAT session is an association between a session
> as seen in the private realm and a session as seen in the public
> realm, by virtue of NAT translation. If a session in the private
> realm were to be represented as (PrivateSrcAddr, PrivateDstAddr,
> TransportProtocol, PrivateSrcPort, PrivateDstPort) and the
> same session in the public realm were to be represented as
> (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort,
> PublicDstPort), the NAT session will provide the translation
> glue between the two session representations.
>
> NEW:
>
>
> NAT Session - A NAT session is an association between a session
> as seen in the private realm and a session as seen in the public
> realm, by virtue of NAT translation. If a session in the private
> realm were to be represented as (PrivateSrcAddr, PrivateDstAddr,
> TransportProtocol, PrivateSrcPort, PrivateDstPort) and the
> same session in the public realm were to be represented as
> (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort,
> PublicDstPort), the NAT session will provide the translation
> glue between the two session representations. NAT sessions in
> the document are restricted to sessions based on TCP and UDP
> only . In the future, NAT sessions may be extended to be based
> on other transport protocols such as SCTP, UDP-lite and DCCP.
>
>
> -----------
> Section 5. Definitions
>
> OLD:
> natAddrBindEntry OBJECT-TYPE
> SYNTAX NatAddrBindEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "Each entry in this table holds information about
> an active address BIND. These entries are lost
> upon agent restart."
> INDEX { ifIndex, natAddrBindLocalAddrType,
> natAddrBindLocalAddr }
> ::= { natAddrBindTable 1 }
>
> NEW:
> natAddrBindEntry OBJECT-TYPE
> SYNTAX NatAddrBindEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "Each entry in this table holds information about
> an active address BIND. These entries are lost
> upon agent restart.
>
> This row has indexing which may create variables with
> more than 128 subidentifiers. Implementers of this table
> must be careful not to create entries that would result
> in OIDs which exceed the 128 subidentifier limit.
> Otherwise, the information cannot be accessed using
> SNMPv1, SNMPv2c or SNMPv3."
>
> INDEX { ifIndex, natAddrBindLocalAddrType,
> natAddrBindLocalAddr }
> ::= { natAddrBindTable 1 }
>
> -----
>
> OLD:
> natAddrBindLocalAddr OBJECT-TYPE
> SYNTAX InetAddress
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This object represents the private-realm specific network
> layer address, which maps to the public-realm address
> represented by natAddrBindGlobalAddr.
>
>
> The type of this address is determined by the value of
> the natAddrBindLocalAddrType object.
>
> As this object is used in the index for the
> natAddrBindTable, implementers of this table should be
> careful not to create entries that would result in OIDs
> with more than 128 subidentifiers; else the information
> cannot be accessed using SNMPv1, SNMPv2c or SNMPv3."
>
> ::= { natAddrBindEntry 2 }
>
> NEW:
> natAddrBindLocalAddr OBJECT-TYPE
> SYNTAX InetAddress
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This object represents the private-realm specific network
> layer address, which maps to the public-realm address
> represented by natAddrBindGlobalAddr.
>
>
> The type of this address is determined by the value of
> the natAddrBindLocalAddrType object."
>
>
> ::= { natAddrBindEntry 2 }
>
> ------
>
> OLD:
>
> natAddrPortBindEntry OBJECT-TYPE
> SYNTAX NatAddrPortBindEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "Each entry in the this table holds information
> about a NAPT bind that is currently active.
> These entries are lost upon agent restart."
> INDEX { ifIndex, natAddrPortBindLocalAddrType,
> natAddrPortBindLocalAddr, natAddrPortBindLocalPort,
> natAddrPortBindProtocol }
> ::= { natAddrPortBindTable 1 }
>
> NEW:
>
> natAddrPortBindEntry OBJECT-TYPE
> SYNTAX NatAddrPortBindEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "Each entry in the this table holds information
> about a NAPT bind that is currently active.
> These entries are lost upon agent restart.
>
> This row has indexing which may create variables with
> more than 128 subidentifiers. Implementers of this table
> must be careful not to create entries which would result
> in OIDs that exceed the 128 subidentifier limit.
> Otherwise, the information cannot be accessed using
> SNMPv1, SNMPv2c or SNMPv3."
> INDEX { ifIndex, natAddrPortBindLocalAddrType,
> natAddrPortBindLocalAddr, natAddrPortBindLocalPort,
> natAddrPortBindProtocol }
> ::= { natAddrPortBindTable 1 }
>
> ------
>
> OLD:
> natAddrPortBindLocalAddr OBJECT-TYPE
> SYNTAX InetAddress
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This object represents the private-realm specific network
> layer address which, in conjunction with
> natAddrPortBindLocalPort, maps to the public-realm
> network layer address and transport id represented by
> natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort
> respectively.
>
>
> The type of this address is determined by the value of
> the natAddrPortBindLocalAddrType object.
>
>
> As this object is used in the index for the
> natAddrPortBindTable, implementers of this table should
> be careful not to create entries that would result in
> OIDs with more than 128 subidentifiers; else the
> information cannot be accessed using SNMPv1, SNMPv2c or
> SNMPv3."
> ::= { natAddrPortBindEntry 2 }
>
> NEW:
> natAddrPortBindLocalAddr OBJECT-TYPE
> SYNTAX InetAddress
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This object represents the private-realm specific network
> layer address which, in conjunction with
> natAddrPortBindLocalPort, maps to the public-realm
> network layer address and transport id represented by
> natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort
> respectively.
>
>
> The type of this address is determined by the value of
> the natAddrPortBindLocalAddrType object."
> ::= { natAddrPortBindEntry 2 }
>
> -----
>
> OLD:
> natMIB MODULE-IDENTITY
> LAST-UPDATED "200404180000Z"
> ORGANIZATION "Individuals"
>
> NEW:
> natMIB MODULE-IDENTITY
> LAST-UPDATED "200404180000Z"
> ORGANIZATION "IETF Transport Area"
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] FW: Protocol Action: 'Definitions of Mana… Jean-Francois Mule
- [ipcdn] RE: Protocol Action: 'Definitions of Mana… Wijnen, Bert (Bert)