From mailman-admin@ietf.org Sat Feb 1 10:30:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08392 for ; Sat, 1 Feb 2003 10:30:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11FYEJ08368 for ; Sat, 1 Feb 2003 10:34:14 -0500 Date: Sat, 01 Feb 2003 10:34:14 -0500 Message-ID: <20030201153414.8821.27310.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nat-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nat-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nat-archive@lists.ietf.org: List Password // URL ---- -------- nat@ietf.org qLLL https://www1.ietf.org/mailman/options/nat/nat-archive%40lists.ietf.org From nat-admin@ietf.org Tue Feb 4 11:14:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26696 for ; Tue, 4 Feb 2003 11:14:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GHbJ05148; Tue, 4 Feb 2003 11:17:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13M6GJ29365 for ; Mon, 3 Feb 2003 17:06:16 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23234 for ; Mon, 3 Feb 2003 17:00:34 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA03361 for ; Mon, 3 Feb 2003 17:16:47 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma003343; Mon, 3 Feb 03 17:16:25 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Mon, 03 Feb 2003 17:04:22 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 3 Feb 2003 17:04:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 3 Feb 2003 17:04:21 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA602F5E@NHROCMBX1.ets.enterasys.com> Thread-Topic: NAT MIB Thread-Index: AcLLzEqaQmZa5Ax+Q6upHoTKLcOO0AAA8GAQ From: "Harrington, David" To: X-OriginalArrivalTime: 03 Feb 2003 22:04:21.0788 (UTC) FILETIME=[34B79DC0:01C2CBD0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h13M6GJ29366 Subject: [NAT] NAT MIB Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Here is my first review of the NAT MIB (draft-ietf-nat-natmib-05.txt): section 4.3 "Likewise, the session entries are derived from the Binds and an entry MUST not exist in the Session table without a corresponding Bind table entry." What is the behavior expected when a Bind table entry is deleted, and session entry exists? MUST the session entry be deleted as well, or MUST the Bind entry NOT be deleted while there is a reference to it? section 5 "Following is the list of protocol specific information, identified at this point, which could potentially require protocol specific extensions to this mib: o Each protocol could support its set of timers and/or other protocol specific configuration parameters for operation with NAT. o Statistics could be maintained per protocol, and type of statistics could be protocol specific. " To ensure that extensions play by the same rules, these should probably be turned into SHOULDs. It will not help interoperability if extension X1 provides timers and counters, while X2 supports only timers, and X3 supports only counters, and so on. The purpose of IETF documents is to define standards - what is the *standard* to be followed when implementing extensions to this mib? When is it appropriate to add timers? When is it appropriate to add counters? The MIB: General comments: I recommend putting the NAT-TC MIB before the NAT-MIB in the document, or simply defining the TC within the NAT-MIB (which will work better with many compilers). I found it irritating to need to work past a long list of authors' addresses to get to the actual mib contents. I don't feel the long list is necessary. I recommend using xxxRowStatus, not simply xxxStatus. Using xxxRowStatus clearly indicates that the object reflects the status of the row, not about the status of the thing modeled in the row. In addition, RowStatus objects should contain instructions in the description about modifications. From RFC2579, RowStatus Textual Convention: " This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'." For StorageType objects, the REFERENCE identifies RFC2578. RowStatus objects however have no reference clause (even though RowStatus is far more complex); why the inconsistency? RFC2119 wordings - there are a number of descriptions that are written with "requirements" that would be better expressed using RFC2119 keywords, to ensure interoperability. For example: natConfLocalPortFrom says "if ..., the value of this object is 0." It would be better to say that the value of this object MUST BE 0. (and it would probably be better to spell out "zero" rather than using the number 0. There are objects called "local" and "global"; are these synonymous with "private" and "public"? If so, can the terminology be modified to use one set consistently? Specific Objects: natConfAddrMapIndex - is this a priority setting? "Address map entries are applied in the order specified by natConfAddrMapIndex." If so, why not name the object accordingly, such as natConfAddrPriority? The fact that it is part of the index should generally not influence the object name - the meaning of the object should be reflected in the name. "In the order specified" is ambiguous - is that ascending or descending order? natConfLocalAddrFrom - why a size range of (0..20)? The description says the object specifies the IP address; why does it have to be an IP address? why not also provide support for other addressing formats? Is NAT supposed to be obsoleted for IPv6 networks? natConfLocalPortFrom: would InetPortNumber from RFC3291 be appropriate here? natConfGlobalAddrTo - "For a static NAT, the number of addresses in the range defined by natConfGlobalAddrFrom and natConfGlobalAddrTo should be equal to the number of addresses in the range defined by natConfLocalAddrFrom and natConfLocalAddrTo." What is the expected behavior if the ranges are NOT equal? or should this be a MUST BE to ensure interoperability between applications and agent implementations? natConfGlobalPortTo - it apperas the description might have benefitted from cut and paste; it is missing random words, such as "If this conceptual describes NAPT," and "in the range of ports being to." natConfProtocol - "specifies a protocol identifier." - so should this be an enumeration that supports only one selection at a time, or BITS which allows multiple selections at a time? Can I reasonably select all four bits simultaneously? What is the expected behavior if I do so? natConfUdpDefIdleTimeout, natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, natConfTcpDefIdleTimeout - why not put these into a table with a protocol identifier object, and reserved entry for defaults? (such as the natConfProtTable that follows?) natConfProtEntry - what exactly is the purpose of these entries? If "Each entry points to a protocol-specific table", and each protocol type has one associated table, then why do I need multiple entries for the same protocol type? Don't they all point to the same table? or do the entries actually point to specific ROWS in a protocol-specific table? The natConfProtTable seems complex to me, as does the whole set of protocol config scalars and tables. For TCP, the configuation parameters are all over the place - you have scalars for defaults; IdleTimeouts in natConfProtEntry, and NegTimeout in the natConfTcpTable. It seems to me this could all be greatly simplified by combining them: natConfProtEntry natConfProtName SnmpAdminString, natConfProtType NATProtocolType, natConfProtSpecName SnmpAdminString, -- "default" has the default values natConfProtIdleTimeout Integer32, natConfProtNegTimeout Integer32, natConfProtRowStatus RowStatus If you believe it is important to have protocol-specific tables, then consider putting all the protocol-specific parameters into the same table: natConfTcpEntry natConfTcpName SnmpAdminString, -- "default" has the default settings natConfProtIdleTimeout Integer32, natConfTcpNegTimeout Integer32, natConfTcpRowStatus RowStatus } natConfProtName isn't very clear as to what the name is meant to refer to. Is it expected that it will be "tcp" or "tcp configuration #1" or "VoIP config"? Are these rows expected to be created by management applications, or by agents? Assuming applications, because there is a RowStatus, how is it expected that administrators will use this naming capability? Is this for grouping multiple configs into a single policy (e.g. "policy#1" = UDP(timout=3), TCP(timeout=7, negtimeout=12), ICMP(timeout=4))? natConfProtType depends on the agent understanding the mapping between a type (tcp) and the table that supports that type. Why not just use an OID to identify the associated table? natConfProtSpecName - why not use a RowPointer (RFC2579), which would encode the OID of the protocol-specific table AND the desired row in the table into one object? I think that would leave you with one table to provide human-readable group names with pointers to the specific config rows, plus a per-protocol table with config parameters: natConfProtEntry natConfProtGroupName SnmpAdminString, natConfProtSpec RowPointer natConfProtRowStatus RowStatus } natConfTcpEntry natConfTcpName SnmpAdminString, -- "default" has the default settings natConfProtIdleTimeout Integer32, natConfTcpNegTimeout Integer32, natConfTcpRowStatus RowStatus } natConfAddressRiseThreshold - How does one calculate the usage percentage? I didn't see any object specifying the number of entries permitted in the table. Why does the number of entries need to be fixed? i.e. if I implement the table to grow dynamically as needed, would I ever use the notification? If one implementation uses statically-sized maps and another uses dynamically sized maps, what should the managing application know and expect? If I have a dynamically growing table, should there be some limit that can be specified by the administrator (or the agent implementor)? natConfAddressRiseThreshold uses naming inconsistent with all other objects that use the template natConfAddrXXXX. Inconsistent naming like this make it much harder to utilize a mib. natAddrBindTable and natAddrPortBindtable contain basically the same information, and the BindIDs need to be unique across both tables. Why not just build one table that can support both address and port binds, with port 0 being used for address-only binds? natAddrBindTable - the description contains two sentences that seem to say the same thing. natAddrBindDirection - if this is associated with an address map direction, whose value is the same, why do we need both objects? Can't one be derived from the other? If natConfAddrMapDirection depicts the direction (inbound vs outbound), then doesn't natAddrBindDirection depict something other than direction? natAddrXXXXLocalAddrXXXX objects discuss how they relate to natAddrXXXXGlobalAddrXXXX objects, and vice-versa. Why not use the description of natAddrBindTable or Entry to describe the intent to map between local and global addresses/ports? Then you can use the actual address object to discuss only that object. natAddrBindAddrMapname - what happens if the address map is deleted? badValue is an SNMPv1 error code. This is not the correct error code to return when using SNMPv2c or SNMPv3 or SNMPvX or a non-SNMP protocol using this mib. It would be best to not specify the error code to be returned, and let the protocol define the correct error code for the situation. natAddrBindOrigin - why is this needed? What does an application/operator use this for? Is the static/dynamic aspects of this somewhat redundant with natAddrBindType? natSessionBindId - the wording needs to be cleaned up. natSessionDirection - how does this differ from the direction in the bind table or the direction in the address map table? natSessionUpTime - There is significantly more overhead involved in keeping this session-uptime accurate than would be involved in just statically recording the start time of the session, and then calculating the delta off the box. It would be simpler to record the sysUpTime at the start of the session and let the application calculate the uptime of the session by comparing the value to the current sysUpTime. This is done routinely in SNMP for other time-delta calculations. natSessionProtocolType - I don't know why there is a tutorial contained in the description clause; how does this relate to this mib? natSessionxxxxPort - could InetPortNumber be used here? Would the private and public addresses in the session table be accurately described as local and global addresses, as used in the address map tables, and so on? There should be consistency in naming. natSessionCurrentIdleTime - as discussed above, this might be better as a timestamp showing when a packet was last detected. xxxSecondBindId - as mentioned above, it is better to not specify the error code. natProtocolStatsName - this is a protocoltype, not a name; why not call it natProtocolStatsProtocol? natAddrMapStatsAddrUsed - for static assignments, shouldn't the number be one? natInterfaceStatsEntry - wouldn't it be useful to know how many were not translated? natAddressUseRising - wouldn't this aalso be useful when an operator added so many static entries that it exceeded the threshold? natPacketDiscard - shouldn't there be an object to specify the suppression time interval? It could default to 5 seconds, but be configurable by the administrator. The compliance statements have lots of optional objects. If they are important, they shouldn't be optional. If they aren't important, they shouldn't be in the mib. The boilerplates for section 2 and section 7 have changed; the document should be updated accordingly. SNMPv3 RFCs have been renumbered (when they were advanced); the references should be updated. David Harrington Network Management Architect Office of the CTO Enterasys Networks _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From mailnull@www1.ietf.org Tue Feb 4 11:16:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26885 for ; Tue, 4 Feb 2003 11:16:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14GM5t05397 for nat-archive@odin.ietf.org; Tue, 4 Feb 2003 11:22:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GHbJ05148; Tue, 4 Feb 2003 11:17:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13M6GJ29365 for ; Mon, 3 Feb 2003 17:06:16 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23234 for ; Mon, 3 Feb 2003 17:00:34 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA03361 for ; Mon, 3 Feb 2003 17:16:47 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma003343; Mon, 3 Feb 03 17:16:25 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Mon, 03 Feb 2003 17:04:22 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 3 Feb 2003 17:04:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 3 Feb 2003 17:04:21 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA602F5E@NHROCMBX1.ets.enterasys.com> Thread-Topic: NAT MIB Thread-Index: AcLLzEqaQmZa5Ax+Q6upHoTKLcOO0AAA8GAQ From: "Harrington, David" To: X-OriginalArrivalTime: 03 Feb 2003 22:04:21.0788 (UTC) FILETIME=[34B79DC0:01C2CBD0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h13M6GJ29366 Subject: [NAT] NAT MIB Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Here is my first review of the NAT MIB (draft-ietf-nat-natmib-05.txt): section 4.3 "Likewise, the session entries are derived from the Binds and an entry MUST not exist in the Session table without a corresponding Bind table entry." What is the behavior expected when a Bind table entry is deleted, and session entry exists? MUST the session entry be deleted as well, or MUST the Bind entry NOT be deleted while there is a reference to it? section 5 "Following is the list of protocol specific information, identified at this point, which could potentially require protocol specific extensions to this mib: o Each protocol could support its set of timers and/or other protocol specific configuration parameters for operation with NAT. o Statistics could be maintained per protocol, and type of statistics could be protocol specific. " To ensure that extensions play by the same rules, these should probably be turned into SHOULDs. It will not help interoperability if extension X1 provides timers and counters, while X2 supports only timers, and X3 supports only counters, and so on. The purpose of IETF documents is to define standards - what is the *standard* to be followed when implementing extensions to this mib? When is it appropriate to add timers? When is it appropriate to add counters? The MIB: General comments: I recommend putting the NAT-TC MIB before the NAT-MIB in the document, or simply defining the TC within the NAT-MIB (which will work better with many compilers). I found it irritating to need to work past a long list of authors' addresses to get to the actual mib contents. I don't feel the long list is necessary. I recommend using xxxRowStatus, not simply xxxStatus. Using xxxRowStatus clearly indicates that the object reflects the status of the row, not about the status of the thing modeled in the row. In addition, RowStatus objects should contain instructions in the description about modifications. From RFC2579, RowStatus Textual Convention: " This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'." For StorageType objects, the REFERENCE identifies RFC2578. RowStatus objects however have no reference clause (even though RowStatus is far more complex); why the inconsistency? RFC2119 wordings - there are a number of descriptions that are written with "requirements" that would be better expressed using RFC2119 keywords, to ensure interoperability. For example: natConfLocalPortFrom says "if ..., the value of this object is 0." It would be better to say that the value of this object MUST BE 0. (and it would probably be better to spell out "zero" rather than using the number 0. There are objects called "local" and "global"; are these synonymous with "private" and "public"? If so, can the terminology be modified to use one set consistently? Specific Objects: natConfAddrMapIndex - is this a priority setting? "Address map entries are applied in the order specified by natConfAddrMapIndex." If so, why not name the object accordingly, such as natConfAddrPriority? The fact that it is part of the index should generally not influence the object name - the meaning of the object should be reflected in the name. "In the order specified" is ambiguous - is that ascending or descending order? natConfLocalAddrFrom - why a size range of (0..20)? The description says the object specifies the IP address; why does it have to be an IP address? why not also provide support for other addressing formats? Is NAT supposed to be obsoleted for IPv6 networks? natConfLocalPortFrom: would InetPortNumber from RFC3291 be appropriate here? natConfGlobalAddrTo - "For a static NAT, the number of addresses in the range defined by natConfGlobalAddrFrom and natConfGlobalAddrTo should be equal to the number of addresses in the range defined by natConfLocalAddrFrom and natConfLocalAddrTo." What is the expected behavior if the ranges are NOT equal? or should this be a MUST BE to ensure interoperability between applications and agent implementations? natConfGlobalPortTo - it apperas the description might have benefitted from cut and paste; it is missing random words, such as "If this conceptual describes NAPT," and "in the range of ports being to." natConfProtocol - "specifies a protocol identifier." - so should this be an enumeration that supports only one selection at a time, or BITS which allows multiple selections at a time? Can I reasonably select all four bits simultaneously? What is the expected behavior if I do so? natConfUdpDefIdleTimeout, natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, natConfTcpDefIdleTimeout - why not put these into a table with a protocol identifier object, and reserved entry for defaults? (such as the natConfProtTable that follows?) natConfProtEntry - what exactly is the purpose of these entries? If "Each entry points to a protocol-specific table", and each protocol type has one associated table, then why do I need multiple entries for the same protocol type? Don't they all point to the same table? or do the entries actually point to specific ROWS in a protocol-specific table? The natConfProtTable seems complex to me, as does the whole set of protocol config scalars and tables. For TCP, the configuation parameters are all over the place - you have scalars for defaults; IdleTimeouts in natConfProtEntry, and NegTimeout in the natConfTcpTable. It seems to me this could all be greatly simplified by combining them: natConfProtEntry natConfProtName SnmpAdminString, natConfProtType NATProtocolType, natConfProtSpecName SnmpAdminString, -- "default" has the default values natConfProtIdleTimeout Integer32, natConfProtNegTimeout Integer32, natConfProtRowStatus RowStatus If you believe it is important to have protocol-specific tables, then consider putting all the protocol-specific parameters into the same table: natConfTcpEntry natConfTcpName SnmpAdminString, -- "default" has the default settings natConfProtIdleTimeout Integer32, natConfTcpNegTimeout Integer32, natConfTcpRowStatus RowStatus } natConfProtName isn't very clear as to what the name is meant to refer to. Is it expected that it will be "tcp" or "tcp configuration #1" or "VoIP config"? Are these rows expected to be created by management applications, or by agents? Assuming applications, because there is a RowStatus, how is it expected that administrators will use this naming capability? Is this for grouping multiple configs into a single policy (e.g. "policy#1" = UDP(timout=3), TCP(timeout=7, negtimeout=12), ICMP(timeout=4))? natConfProtType depends on the agent understanding the mapping between a type (tcp) and the table that supports that type. Why not just use an OID to identify the associated table? natConfProtSpecName - why not use a RowPointer (RFC2579), which would encode the OID of the protocol-specific table AND the desired row in the table into one object? I think that would leave you with one table to provide human-readable group names with pointers to the specific config rows, plus a per-protocol table with config parameters: natConfProtEntry natConfProtGroupName SnmpAdminString, natConfProtSpec RowPointer natConfProtRowStatus RowStatus } natConfTcpEntry natConfTcpName SnmpAdminString, -- "default" has the default settings natConfProtIdleTimeout Integer32, natConfTcpNegTimeout Integer32, natConfTcpRowStatus RowStatus } natConfAddressRiseThreshold - How does one calculate the usage percentage? I didn't see any object specifying the number of entries permitted in the table. Why does the number of entries need to be fixed? i.e. if I implement the table to grow dynamically as needed, would I ever use the notification? If one implementation uses statically-sized maps and another uses dynamically sized maps, what should the managing application know and expect? If I have a dynamically growing table, should there be some limit that can be specified by the administrator (or the agent implementor)? natConfAddressRiseThreshold uses naming inconsistent with all other objects that use the template natConfAddrXXXX. Inconsistent naming like this make it much harder to utilize a mib. natAddrBindTable and natAddrPortBindtable contain basically the same information, and the BindIDs need to be unique across both tables. Why not just build one table that can support both address and port binds, with port 0 being used for address-only binds? natAddrBindTable - the description contains two sentences that seem to say the same thing. natAddrBindDirection - if this is associated with an address map direction, whose value is the same, why do we need both objects? Can't one be derived from the other? If natConfAddrMapDirection depicts the direction (inbound vs outbound), then doesn't natAddrBindDirection depict something other than direction? natAddrXXXXLocalAddrXXXX objects discuss how they relate to natAddrXXXXGlobalAddrXXXX objects, and vice-versa. Why not use the description of natAddrBindTable or Entry to describe the intent to map between local and global addresses/ports? Then you can use the actual address object to discuss only that object. natAddrBindAddrMapname - what happens if the address map is deleted? badValue is an SNMPv1 error code. This is not the correct error code to return when using SNMPv2c or SNMPv3 or SNMPvX or a non-SNMP protocol using this mib. It would be best to not specify the error code to be returned, and let the protocol define the correct error code for the situation. natAddrBindOrigin - why is this needed? What does an application/operator use this for? Is the static/dynamic aspects of this somewhat redundant with natAddrBindType? natSessionBindId - the wording needs to be cleaned up. natSessionDirection - how does this differ from the direction in the bind table or the direction in the address map table? natSessionUpTime - There is significantly more overhead involved in keeping this session-uptime accurate than would be involved in just statically recording the start time of the session, and then calculating the delta off the box. It would be simpler to record the sysUpTime at the start of the session and let the application calculate the uptime of the session by comparing the value to the current sysUpTime. This is done routinely in SNMP for other time-delta calculations. natSessionProtocolType - I don't know why there is a tutorial contained in the description clause; how does this relate to this mib? natSessionxxxxPort - could InetPortNumber be used here? Would the private and public addresses in the session table be accurately described as local and global addresses, as used in the address map tables, and so on? There should be consistency in naming. natSessionCurrentIdleTime - as discussed above, this might be better as a timestamp showing when a packet was last detected. xxxSecondBindId - as mentioned above, it is better to not specify the error code. natProtocolStatsName - this is a protocoltype, not a name; why not call it natProtocolStatsProtocol? natAddrMapStatsAddrUsed - for static assignments, shouldn't the number be one? natInterfaceStatsEntry - wouldn't it be useful to know how many were not translated? natAddressUseRising - wouldn't this aalso be useful when an operator added so many static entries that it exceeded the threshold? natPacketDiscard - shouldn't there be an object to specify the suppression time interval? It could default to 5 seconds, but be configurable by the administrator. The compliance statements have lots of optional objects. If they are important, they shouldn't be optional. If they aren't important, they shouldn't be in the mib. The boilerplates for section 2 and section 7 have changed; the document should be updated accordingly. SNMPv3 RFCs have been renumbered (when they were advanced); the references should be updated. David Harrington Network Management Architect Office of the CTO Enterasys Networks _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From nat-admin@ietf.org Tue Feb 4 11:18:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26946 for ; Tue, 4 Feb 2003 11:18:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GLcJ05337; Tue, 4 Feb 2003 11:21:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FRVJ01184 for ; Tue, 4 Feb 2003 10:27:31 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24966 for ; Tue, 4 Feb 2003 10:21:29 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA08439 for ; Tue, 4 Feb 2003 10:36:54 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma008246; Tue, 4 Feb 03 10:34:07 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Tue, 04 Feb 2003 10:22:04 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Feb 2003 10:22:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Feb 2003 10:22:03 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA602F62@NHROCMBX1.ets.enterasys.com> Thread-Topic: nat mib review addendum Thread-Index: AcLMYQxEnncZ7k+AT5uMYj38HviteQ== From: "Harrington, David" To: X-OriginalArrivalTime: 04 Feb 2003 15:22:03.0683 (UTC) FILETIME=[2BB2D730:01C2CC61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14FRVJ01185 Subject: [NAT] nat mib review addendum Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, For the module-identity clause, please use the following format: ::= { mib-2 nnn } -- nnn to be assigned by IANA David Harrington Network Management Architect Office of the CTO Enterasys Networks _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From mailnull@www1.ietf.org Tue Feb 4 11:19:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27081 for ; Tue, 4 Feb 2003 11:19:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14GPRo05625 for nat-archive@odin.ietf.org; Tue, 4 Feb 2003 11:25:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GLcJ05337; Tue, 4 Feb 2003 11:21:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FRVJ01184 for ; Tue, 4 Feb 2003 10:27:31 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24966 for ; Tue, 4 Feb 2003 10:21:29 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA08439 for ; Tue, 4 Feb 2003 10:36:54 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma008246; Tue, 4 Feb 03 10:34:07 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Tue, 04 Feb 2003 10:22:04 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Feb 2003 10:22:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Feb 2003 10:22:03 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA602F62@NHROCMBX1.ets.enterasys.com> Thread-Topic: nat mib review addendum Thread-Index: AcLMYQxEnncZ7k+AT5uMYj38HviteQ== From: "Harrington, David" To: X-OriginalArrivalTime: 04 Feb 2003 15:22:03.0683 (UTC) FILETIME=[2BB2D730:01C2CC61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14FRVJ01185 Subject: [NAT] nat mib review addendum Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, For the module-identity clause, please use the following format: ::= { mib-2 nnn } -- nnn to be assigned by IANA David Harrington Network Management Architect Office of the CTO Enterasys Networks _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From nat-admin@ietf.org Thu Feb 6 22:06:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13884 for ; Thu, 6 Feb 2003 22:06:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h173ATp20232; Thu, 6 Feb 2003 22:10:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1737Ap19831 for ; Thu, 6 Feb 2003 22:07:10 -0500 Received: from THORONDOR.WWP.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13646 for ; Thu, 6 Feb 2003 21:59:54 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NAT] NAT MIB Date: Thu, 6 Feb 2003 19:03:31 -0800 Message-ID: <4E9A9436C008314EAA32033B23E96FD9187C50@thorondor.wwp.com> Thread-Topic: NAT MIB Thread-Index: AcLLzEqaQmZa5Ax+Q6upHoTKLcOO0AAA8GAQADFq9uA= From: "Rohit Rohit" To: "Harrington, David" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1737Ap19832 Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi David, Thanks for your comments. My comments are inline. Please look for [ROHIT]. -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: Monday, February 03, 2003 2:04 PM To: nat@ietf.org Subject: [NAT] NAT MIB Here is my first review of the NAT MIB (draft-ietf-nat-natmib-05.txt): section 4.3 "Likewise, the session entries are derived from the Binds and an entry MUST not exist in the Session table without a corresponding Bind table entry." What is the behavior expected when a Bind table entry is deleted, and session entry exists? MUST the session entry be deleted as well, or MUST the Bind entry NOT be deleted while there is a reference to it? [ROHIT] Before deleting a bind entry, all the session entries corresponding to the bind entries must be deleted. We will specifically mention this in the next version. section 5 "Following is the list of protocol specific information, identified at this point, which could potentially require protocol specific extensions to this mib: o Each protocol could support its set of timers and/or other protocol specific configuration parameters for operation with NAT. o Statistics could be maintained per protocol, and type of statistics could be protocol specific. " To ensure that extensions play by the same rules, these should probably be turned into SHOULDs. It will not help interoperability if extension X1 provides timers and counters, while X2 supports only timers, and X3 supports only counters, and so on. The purpose of IETF documents is to define standards - what is the *standard* to be followed when implementing extensions to this mib? When is it appropriate to add timers? When is it appropriate to add counters? [ROHIT] I'm not absolutely certain, we can place restrictions on extensions. For e.g. some protocols may require timers in addition to the IdleTimeOut (TCP being an case in point where we have a natConfTcpNegTimeout). As for counters, yes we could globally have translation counters, but again counters specific to the protocol use of NAT cannot be decided in the NAT-MIB. In fact, the fact that NAT-specific information about other protocols cannot be decided upfront is precisely the reason why we have included the complexity of these extension tables!! And coming to the extension tables, I have this feeling (not sure how many of you share it) that they add little value and more complexity to the MIB. If there is little use for it (which we need to find out), maybe we could drop that from the MIB. Thoughts??? The MIB: General comments: I recommend putting the NAT-TC MIB before the NAT-MIB in the document, or simply defining the TC within the NAT-MIB (which will work better with many compilers). [ROHIT] the basic idea behind defining this TC in the separate MIB was to extend the protocols list without touching the NAT-MIB. But we can surely define the NAT-TC MIB before NAT-MIB. I found it irritating to need to work past a long list of authors' addresses to get to the actual mib contents. I don't feel the long list is necessary. [ROHIT] We will choose a document editor and list only the editor's name here. I recommend using xxxRowStatus, not simply xxxStatus. Using xxxRowStatus clearly indicates that the object reflects the status of the row, not about the status of the thing modeled in the row. [ROHIT] will do that. In addition, RowStatus objects should contain instructions in the description about modifications. From RFC2579, RowStatus Textual Convention: " This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'." [ROHIT] I tends to agree. I wanted to let this open for the implementation. But now i think we should add this. For StorageType objects, the REFERENCE identifies RFC2578. RowStatus objects however have no reference clause (even though RowStatus is far more complex); why the inconsistency? [ROHIT] RowStatus is very common in the MIBS while StorageType is not; and thats why this inconsistency. We will fix this. RFC2119 wordings - there are a number of descriptions that are written with "requirements" that would be better expressed using RFC2119 keywords, to ensure interoperability. For example: natConfLocalPortFrom says "if ..., the value of this object is 0." It would be better to say that the value of this object MUST BE 0. (and it would probably be better to spell out "zero" rather than using the number 0. [ROHIT] Thanks for suugesting the better words. There are objects called "local" and "global"; are these synonymous with "private" and "public"? If so, can the terminology be modified to use one set consistently? [ROHIT] The terms public and private are used throughout the document in the context of networks, while the terms local and global are used when referring to addresses and ports. Specific Objects: natConfAddrMapIndex - is this a priority setting? "Address map entries are applied in the order specified by natConfAddrMapIndex." If so, why not name the object accordingly, such as natConfAddrPriority? The fact that it is part of the index should generally not influence the object name - the meaning of the object should be reflected in the name. "In the order specified" is ambiguous - is that ascending or descending order? [ROHIT] I get your point here; but i think that priority word may be confusing too as NAT by itself doesn't have any concept of 'priority'. natConfLocalAddrFrom - why a size range of (0..20)? The description says the object specifies the IP address; why does it have to be an IP address? why not also provide support for other addressing formats? Is NAT supposed to be obsoleted for IPv6 networks? [ROHIT] One of the index for the bind table is the address. As the value of this object is going to be appended to OIDs of other MIB objects in the bind table. Now the total number of sub-identifiers in an OID cannot exceed more than 128. To ensure this, we need to place a restriction on the size of the index objects. As we wanted to be consistent, so we used the same restriction everywhere. The size (0..20) still covers IPv6. natConfLocalPortFrom: would InetPortNumber from RFC3291 be appropriate here? [ROHIT] wil do that. natConfGlobalAddrTo - "For a static NAT, the number of addresses in the range defined by natConfGlobalAddrFrom and natConfGlobalAddrTo should be equal to the number of addresses in the range defined by natConfLocalAddrFrom and natConfLocalAddrTo." What is the expected behavior if the ranges are NOT equal? or should this be a MUST BE to ensure interoperability between applications and agent implementations? [ROHIT] will use 'MUST BE'. natConfGlobalPortTo - it apperas the description might have benefitted from cut and paste; it is missing random words, such as "If this conceptual describes NAPT," and "in the range of ports being to." [ROHIT] will fix this natConfProtocol - "specifies a protocol identifier." - so should this be an enumeration that supports only one selection at a time, or BITS which allows multiple selections at a time? Can I reasonably select all four bits simultaneously? What is the expected behavior if I do so? [ROHIT] The syntax here is BITS; as the same config can be applied to multiple protocols. We can only set the 'other' bit to 1, depending upon the protocol being used (in the category of 'other'). natConfUdpDefIdleTimeout, natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, natConfTcpDefIdleTimeout - why not put these into a table with a protocol identifier object, and reserved entry for defaults? (such as the natConfProtTable that follows?) natConfProtEntry - what exactly is the purpose of these entries? If "Each entry points to a protocol-specific table", and each protocol type has one associated table, then why do I need multiple entries for the same protocol type? Don't they all point to the same table? or do the entries actually point to specific ROWS in a protocol-specific table? The natConfProtTable seems complex to me, as does the whole set of protocol config scalars and tables. For TCP, the configuation parameters are all over the place - you have scalars for defaults; IdleTimeouts in natConfProtEntry, and NegTimeout in the natConfTcpTable. It seems to me this could all be greatly simplified by combining them: natConfProtEntry natConfProtName SnmpAdminString, natConfProtType NATProtocolType, natConfProtSpecName SnmpAdminString, -- "default" has the default values natConfProtIdleTimeout Integer32, natConfProtNegTimeout Integer32, natConfProtRowStatus RowStatus If you believe it is important to have protocol-specific tables, then consider putting all the protocol-specific parameters into the same table: natConfTcpEntry natConfTcpName SnmpAdminString, -- "default" has the default settings natConfProtIdleTimeout Integer32, natConfTcpNegTimeout Integer32, natConfTcpRowStatus RowStatus } natConfProtName isn't very clear as to what the name is meant to refer to. Is it expected that it will be "tcp" or "tcp configuration #1" or "VoIP config"? Are these rows expected to be created by management applications, or by agents? Assuming applications, because there is a RowStatus, how is it expected that administrators will use this naming capability? Is this for grouping multiple configs into a single policy (e.g. "policy#1" = UDP(timout=3), TCP(timeout=7, negtimeout=12), ICMP(timeout=4))? natConfProtType depends on the agent understanding the mapping between a type (tcp) and the table that supports that type. Why not just use an OID to identify the associated table? natConfProtSpecName - why not use a RowPointer (RFC2579), which would encode the OID of the protocol-specific table AND the desired row in the table into one object? I think that would leave you with one table to provide human-readable group names with pointers to the specific config rows, plus a per-protocol table with config parameters: natConfProtEntry natConfProtGroupName SnmpAdminString, natConfProtSpec RowPointer natConfProtRowStatus RowStatus } natConfTcpEntry natConfTcpName SnmpAdminString, -- "default" has the default settings natConfProtIdleTimeout Integer32, natConfTcpNegTimeout Integer32, natConfTcpRowStatus RowStatus } [ROHIT] We had these goals while defining this complex tables 1) If possible, avoid creating the protocol specific tables and just manage with the scalars. ( for udp/icmp etc ) 2) Since most protocols e.g. TCP, UDP, ICMP, have idle timeouts as a common parameter for the configuration, this parameter has been added to the natConfProtTable. 3) We wanted to add built in support for TCP. I agree that we should simplify the tables ( use RowPointer etc). IMHO, we need to asses if we really need protocol extensibility at the cost of adding complexity in the MIB. natConfAddressRiseThreshold - How does one calculate the usage percentage? I didn't see any object specifying the number of entries permitted in the table. Why does the number of entries need to be fixed? i.e. if I implement the table to grow dynamically as needed, would I ever use the notification? If one implementation uses statically-sized maps and another uses dynamically sized maps, what should the managing application know and expect? If I have a dynamically growing table, should there be some limit that can be specified by the administrator (or the agent implementor)? [ROHIT] Basically given an address map, the number of available addresses is fixed. For a dynamic map, the number of users keep varying (depending on request/release of addresses). This parameter is required to indicate to the administrator when the address usage starts increasing and goes beyond a threshold. The main use is to notify the administrator that newer clients coming in might soon start failing on address requests. This can also act as a mechanism to notify the administrator to monitor usage patterns and accordingly configure the address allocations.. natConfAddressRiseThreshold uses naming inconsistent with all other objects that use the template natConfAddrXXXX. Inconsistent naming like this make it much harder to utilize a mib. [ROHIT] will change this. natAddrBindTable and natAddrPortBindtable contain basically the same information, and the BindIDs need to be unique across both tables. Why not just build one table that can support both address and port binds, with port 0 being used for address-only binds? [ROHIT] We didn't merge these tables; as they have different indexes. I get your point; but Port No. column is also used to represent ICMP query id's and as per RFC 792, 0 is a valid value for that field. Echo or Echo Reply Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+- ...... Identifier If code = 0, an identifier to aid in matching echos and replies, may be zero. natAddrBindTable - the description contains two sentences that seem to say the same thing. [ROHIT] will fix this. natAddrBindDirection - if this is associated with an address map direction, whose value is the same, why do we need both objects? Can't one be derived from the other? If natConfAddrMapDirection depicts the direction (inbound vs outbound), then doesn't natAddrBindDirection depict something other than direction? [ROHIT] Address map can be inbound/outbound/both(i.e., inbound and outbound for a bi-directional-NAT ). Well, a BIND may be derived by NAT, based on the sessions noticed in the ingress direction, Egress direction or both. ex: You could generate a BIND for a bi-directional NAT by looking up the address maps for sessions in either direction. Whereas, you would create and reuse the BINDS only for outbound sessions with a traditional NAT. natAddrXXXXLocalAddrXXXX objects discuss how they relate to natAddrXXXXGlobalAddrXXXX objects, and vice-versa. Why not use the description of natAddrBindTable or Entry to describe the intent to map between local and global addresses/ports? Then you can use the actual address object to discuss only that object. [ROHIT] will do that. natAddrBindAddrMapname - what happens if the address map is deleted? badValue is an SNMPv1 error code. This is not the correct error code to return when using SNMPv2c or SNMPv3 or SNMPvX or a non-SNMP protocol using this mib. It would be best to not specify the error code to be returned, and let the protocol define the correct error code for the situation. [ROHIT] will do that. natAddrBindOrigin - why is this needed? What does an application/operator use this for? Is the static/dynamic aspects of this somewhat redundant with natAddrBindType? [ROHIT] The main idea behind this object is to show the creator of the static bind. This was a midcom requirement. natSessionBindId - the wording needs to be cleaned up. [ROHIT] will do. natSessionDirection - how does this differ from the direction in the bind table or the direction in the address map table? [ROHIT] Address map can be inbound/outbound/both(i.e., inbound and outbound for a bi-directional-NAT ). Well, a BIND may be derived by NAT, based on the sessions noticed in the ingress direction, Egress direction or both. ex: You could generate a BIND for a bi-directional NAT by looking up the address maps for sessions in either direction. Whereas, you would create and reuse the BINDS only for outbound sessions with a traditional NAT. Session Direction : The direction of this session with respect to the local network. 'inbound' indicates that this session was initiated from the public network into the private network. 'outbound' indicates that this session was initiated from the private network into the public network." natSessionUpTime - There is significantly more overhead involved in keeping this session-uptime accurate than would be involved in just statically recording the start time of the session, and then calculating the delta off the box. It would be simpler to record the sysUpTime at the start of the session and let the application calculate the uptime of the session by comparing the value to the current sysUpTime. This is done routinely in SNMP for other time-delta calculations. [ROHIT] Agreed. natSessionProtocolType - I don't know why there is a tutorial contained in the description clause; how does this relate to this mib? [ROHIT] wil remove this. natSessionxxxxPort - could InetPortNumber be used here? [ROHIT] Will do that. Would the private and public addresses in the session table be accurately described as local and global addresses, as used in the address map tables, and so on? There should be consistency in naming. [ROHIT] You have a point here. The session table is about addresses and ports, therefore the names of the objects should've used Local and Global - not Private and Public. natSessionCurrentIdleTime - as discussed above, this might be better as a timestamp showing when a packet was last detected. [ROHIT] will take care of this. xxxSecondBindId - as mentioned above, it is better to not specify the error code. [ROHIT] will do . natProtocolStatsName - this is a protocoltype, not a name; why not call it natProtocolStatsProtocol? [ROHIT] will do. natAddrMapStatsAddrUsed - for static assignments, shouldn't the number be one? [ROHIT] The address map may have more than one address, even for a static map. This number should be equal to the number of addresses defined in the address map, for the case of static maps. natInterfaceStatsEntry - wouldn't it be useful to know how many were not translated? [ROHIT] natProtocolStatsRejectCount should take care of this. natAddressUseRising - wouldn't this aalso be useful when an operator added so many static entries that it exceeded the threshold? [ROHIT] static entries are not assigned from the pool; so this notification will not make sense for static entries. natPacketDiscard - shouldn't there be an object to specify the suppression time interval? It could default to 5 seconds, but be configurable by the administrator. [ROHIT] aill add the additional object. The compliance statements have lots of optional objects. If they are important, they shouldn't be optional. If they aren't important, they shouldn't be in the mib. [ROHIT] Many vendors scenario/implementation just suuports the base nat and may not be able to support the optional objects and still be compliant with the MIB. The boilerplates for section 2 and section 7 have changed; the document should be updated accordingly. SNMPv3 RFCs have been renumbered (when they were advanced); the references should be updated. [ROHIT] will do that. Thanks for your comments and we will come back to you with these comments incorporated. Rohit _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From mailnull@www1.ietf.org Thu Feb 6 22:09:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13956 for ; Thu, 6 Feb 2003 22:09:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h173G1L20618 for nat-archive@odin.ietf.org; Thu, 6 Feb 2003 22:16:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h173ATp20232; Thu, 6 Feb 2003 22:10:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1737Ap19831 for ; Thu, 6 Feb 2003 22:07:10 -0500 Received: from THORONDOR.WWP.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13646 for ; Thu, 6 Feb 2003 21:59:54 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NAT] NAT MIB Date: Thu, 6 Feb 2003 19:03:31 -0800 Message-ID: <4E9A9436C008314EAA32033B23E96FD9187C50@thorondor.wwp.com> Thread-Topic: NAT MIB Thread-Index: AcLLzEqaQmZa5Ax+Q6upHoTKLcOO0AAA8GAQADFq9uA= From: "Rohit Rohit" To: "Harrington, David" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1737Ap19832 Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi David, Thanks for your comments. My comments are inline. Please look for [ROHIT]. -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: Monday, February 03, 2003 2:04 PM To: nat@ietf.org Subject: [NAT] NAT MIB Here is my first review of the NAT MIB (draft-ietf-nat-natmib-05.txt): section 4.3 "Likewise, the session entries are derived from the Binds and an entry MUST not exist in the Session table without a corresponding Bind table entry." What is the behavior expected when a Bind table entry is deleted, and session entry exists? MUST the session entry be deleted as well, or MUST the Bind entry NOT be deleted while there is a reference to it? [ROHIT] Before deleting a bind entry, all the session entries corresponding to the bind entries must be deleted. We will specifically mention this in the next version. section 5 "Following is the list of protocol specific information, identified at this point, which could potentially require protocol specific extensions to this mib: o Each protocol could support its set of timers and/or other protocol specific configuration parameters for operation with NAT. o Statistics could be maintained per protocol, and type of statistics could be protocol specific. " To ensure that extensions play by the same rules, these should probably be turned into SHOULDs. It will not help interoperability if extension X1 provides timers and counters, while X2 supports only timers, and X3 supports only counters, and so on. The purpose of IETF documents is to define standards - what is the *standard* to be followed when implementing extensions to this mib? When is it appropriate to add timers? When is it appropriate to add counters? [ROHIT] I'm not absolutely certain, we can place restrictions on extensions. For e.g. some protocols may require timers in addition to the IdleTimeOut (TCP being an case in point where we have a natConfTcpNegTimeout). As for counters, yes we could globally have translation counters, but again counters specific to the protocol use of NAT cannot be decided in the NAT-MIB. In fact, the fact that NAT-specific information about other protocols cannot be decided upfront is precisely the reason why we have included the complexity of these extension tables!! And coming to the extension tables, I have this feeling (not sure how many of you share it) that they add little value and more complexity to the MIB. If there is little use for it (which we need to find out), maybe we could drop that from the MIB. Thoughts??? The MIB: General comments: I recommend putting the NAT-TC MIB before the NAT-MIB in the document, or simply defining the TC within the NAT-MIB (which will work better with many compilers). [ROHIT] the basic idea behind defining this TC in the separate MIB was to extend the protocols list without touching the NAT-MIB. But we can surely define the NAT-TC MIB before NAT-MIB. I found it irritating to need to work past a long list of authors' addresses to get to the actual mib contents. I don't feel the long list is necessary. [ROHIT] We will choose a document editor and list only the editor's name here. I recommend using xxxRowStatus, not simply xxxStatus. Using xxxRowStatus clearly indicates that the object reflects the status of the row, not about the status of the thing modeled in the row. [ROHIT] will do that. In addition, RowStatus objects should contain instructions in the description about modifications. From RFC2579, RowStatus Textual Convention: " This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'." [ROHIT] I tends to agree. I wanted to let this open for the implementation. But now i think we should add this. For StorageType objects, the REFERENCE identifies RFC2578. RowStatus objects however have no reference clause (even though RowStatus is far more complex); why the inconsistency? [ROHIT] RowStatus is very common in the MIBS while StorageType is not; and thats why this inconsistency. We will fix this. RFC2119 wordings - there are a number of descriptions that are written with "requirements" that would be better expressed using RFC2119 keywords, to ensure interoperability. For example: natConfLocalPortFrom says "if ..., the value of this object is 0." It would be better to say that the value of this object MUST BE 0. (and it would probably be better to spell out "zero" rather than using the number 0. [ROHIT] Thanks for suugesting the better words. There are objects called "local" and "global"; are these synonymous with "private" and "public"? If so, can the terminology be modified to use one set consistently? [ROHIT] The terms public and private are used throughout the document in the context of networks, while the terms local and global are used when referring to addresses and ports. Specific Objects: natConfAddrMapIndex - is this a priority setting? "Address map entries are applied in the order specified by natConfAddrMapIndex." If so, why not name the object accordingly, such as natConfAddrPriority? The fact that it is part of the index should generally not influence the object name - the meaning of the object should be reflected in the name. "In the order specified" is ambiguous - is that ascending or descending order? [ROHIT] I get your point here; but i think that priority word may be confusing too as NAT by itself doesn't have any concept of 'priority'. natConfLocalAddrFrom - why a size range of (0..20)? The description says the object specifies the IP address; why does it have to be an IP address? why not also provide support for other addressing formats? Is NAT supposed to be obsoleted for IPv6 networks? [ROHIT] One of the index for the bind table is the address. As the value of this object is going to be appended to OIDs of other MIB objects in the bind table. Now the total number of sub-identifiers in an OID cannot exceed more than 128. To ensure this, we need to place a restriction on the size of the index objects. As we wanted to be consistent, so we used the same restriction everywhere. The size (0..20) still covers IPv6. natConfLocalPortFrom: would InetPortNumber from RFC3291 be appropriate here? [ROHIT] wil do that. natConfGlobalAddrTo - "For a static NAT, the number of addresses in the range defined by natConfGlobalAddrFrom and natConfGlobalAddrTo should be equal to the number of addresses in the range defined by natConfLocalAddrFrom and natConfLocalAddrTo." What is the expected behavior if the ranges are NOT equal? or should this be a MUST BE to ensure interoperability between applications and agent implementations? [ROHIT] will use 'MUST BE'. natConfGlobalPortTo - it apperas the description might have benefitted from cut and paste; it is missing random words, such as "If this conceptual describes NAPT," and "in the range of ports being to." [ROHIT] will fix this natConfProtocol - "specifies a protocol identifier." - so should this be an enumeration that supports only one selection at a time, or BITS which allows multiple selections at a time? Can I reasonably select all four bits simultaneously? What is the expected behavior if I do so? [ROHIT] The syntax here is BITS; as the same config can be applied to multiple protocols. We can only set the 'other' bit to 1, depending upon the protocol being used (in the category of 'other'). natConfUdpDefIdleTimeout, natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, natConfTcpDefIdleTimeout - why not put these into a table with a protocol identifier object, and reserved entry for defaults? (such as the natConfProtTable that follows?) natConfProtEntry - what exactly is the purpose of these entries? If "Each entry points to a protocol-specific table", and each protocol type has one associated table, then why do I need multiple entries for the same protocol type? Don't they all point to the same table? or do the entries actually point to specific ROWS in a protocol-specific table? The natConfProtTable seems complex to me, as does the whole set of protocol config scalars and tables. For TCP, the configuation parameters are all over the place - you have scalars for defaults; IdleTimeouts in natConfProtEntry, and NegTimeout in the natConfTcpTable. It seems to me this could all be greatly simplified by combining them: natConfProtEntry natConfProtName SnmpAdminString, natConfProtType NATProtocolType, natConfProtSpecName SnmpAdminString, -- "default" has the default values natConfProtIdleTimeout Integer32, natConfProtNegTimeout Integer32, natConfProtRowStatus RowStatus If you believe it is important to have protocol-specific tables, then consider putting all the protocol-specific parameters into the same table: natConfTcpEntry natConfTcpName SnmpAdminString, -- "default" has the default settings natConfProtIdleTimeout Integer32, natConfTcpNegTimeout Integer32, natConfTcpRowStatus RowStatus } natConfProtName isn't very clear as to what the name is meant to refer to. Is it expected that it will be "tcp" or "tcp configuration #1" or "VoIP config"? Are these rows expected to be created by management applications, or by agents? Assuming applications, because there is a RowStatus, how is it expected that administrators will use this naming capability? Is this for grouping multiple configs into a single policy (e.g. "policy#1" = UDP(timout=3), TCP(timeout=7, negtimeout=12), ICMP(timeout=4))? natConfProtType depends on the agent understanding the mapping between a type (tcp) and the table that supports that type. Why not just use an OID to identify the associated table? natConfProtSpecName - why not use a RowPointer (RFC2579), which would encode the OID of the protocol-specific table AND the desired row in the table into one object? I think that would leave you with one table to provide human-readable group names with pointers to the specific config rows, plus a per-protocol table with config parameters: natConfProtEntry natConfProtGroupName SnmpAdminString, natConfProtSpec RowPointer natConfProtRowStatus RowStatus } natConfTcpEntry natConfTcpName SnmpAdminString, -- "default" has the default settings natConfProtIdleTimeout Integer32, natConfTcpNegTimeout Integer32, natConfTcpRowStatus RowStatus } [ROHIT] We had these goals while defining this complex tables 1) If possible, avoid creating the protocol specific tables and just manage with the scalars. ( for udp/icmp etc ) 2) Since most protocols e.g. TCP, UDP, ICMP, have idle timeouts as a common parameter for the configuration, this parameter has been added to the natConfProtTable. 3) We wanted to add built in support for TCP. I agree that we should simplify the tables ( use RowPointer etc). IMHO, we need to asses if we really need protocol extensibility at the cost of adding complexity in the MIB. natConfAddressRiseThreshold - How does one calculate the usage percentage? I didn't see any object specifying the number of entries permitted in the table. Why does the number of entries need to be fixed? i.e. if I implement the table to grow dynamically as needed, would I ever use the notification? If one implementation uses statically-sized maps and another uses dynamically sized maps, what should the managing application know and expect? If I have a dynamically growing table, should there be some limit that can be specified by the administrator (or the agent implementor)? [ROHIT] Basically given an address map, the number of available addresses is fixed. For a dynamic map, the number of users keep varying (depending on request/release of addresses). This parameter is required to indicate to the administrator when the address usage starts increasing and goes beyond a threshold. The main use is to notify the administrator that newer clients coming in might soon start failing on address requests. This can also act as a mechanism to notify the administrator to monitor usage patterns and accordingly configure the address allocations.. natConfAddressRiseThreshold uses naming inconsistent with all other objects that use the template natConfAddrXXXX. Inconsistent naming like this make it much harder to utilize a mib. [ROHIT] will change this. natAddrBindTable and natAddrPortBindtable contain basically the same information, and the BindIDs need to be unique across both tables. Why not just build one table that can support both address and port binds, with port 0 being used for address-only binds? [ROHIT] We didn't merge these tables; as they have different indexes. I get your point; but Port No. column is also used to represent ICMP query id's and as per RFC 792, 0 is a valid value for that field. Echo or Echo Reply Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+- ...... Identifier If code = 0, an identifier to aid in matching echos and replies, may be zero. natAddrBindTable - the description contains two sentences that seem to say the same thing. [ROHIT] will fix this. natAddrBindDirection - if this is associated with an address map direction, whose value is the same, why do we need both objects? Can't one be derived from the other? If natConfAddrMapDirection depicts the direction (inbound vs outbound), then doesn't natAddrBindDirection depict something other than direction? [ROHIT] Address map can be inbound/outbound/both(i.e., inbound and outbound for a bi-directional-NAT ). Well, a BIND may be derived by NAT, based on the sessions noticed in the ingress direction, Egress direction or both. ex: You could generate a BIND for a bi-directional NAT by looking up the address maps for sessions in either direction. Whereas, you would create and reuse the BINDS only for outbound sessions with a traditional NAT. natAddrXXXXLocalAddrXXXX objects discuss how they relate to natAddrXXXXGlobalAddrXXXX objects, and vice-versa. Why not use the description of natAddrBindTable or Entry to describe the intent to map between local and global addresses/ports? Then you can use the actual address object to discuss only that object. [ROHIT] will do that. natAddrBindAddrMapname - what happens if the address map is deleted? badValue is an SNMPv1 error code. This is not the correct error code to return when using SNMPv2c or SNMPv3 or SNMPvX or a non-SNMP protocol using this mib. It would be best to not specify the error code to be returned, and let the protocol define the correct error code for the situation. [ROHIT] will do that. natAddrBindOrigin - why is this needed? What does an application/operator use this for? Is the static/dynamic aspects of this somewhat redundant with natAddrBindType? [ROHIT] The main idea behind this object is to show the creator of the static bind. This was a midcom requirement. natSessionBindId - the wording needs to be cleaned up. [ROHIT] will do. natSessionDirection - how does this differ from the direction in the bind table or the direction in the address map table? [ROHIT] Address map can be inbound/outbound/both(i.e., inbound and outbound for a bi-directional-NAT ). Well, a BIND may be derived by NAT, based on the sessions noticed in the ingress direction, Egress direction or both. ex: You could generate a BIND for a bi-directional NAT by looking up the address maps for sessions in either direction. Whereas, you would create and reuse the BINDS only for outbound sessions with a traditional NAT. Session Direction : The direction of this session with respect to the local network. 'inbound' indicates that this session was initiated from the public network into the private network. 'outbound' indicates that this session was initiated from the private network into the public network." natSessionUpTime - There is significantly more overhead involved in keeping this session-uptime accurate than would be involved in just statically recording the start time of the session, and then calculating the delta off the box. It would be simpler to record the sysUpTime at the start of the session and let the application calculate the uptime of the session by comparing the value to the current sysUpTime. This is done routinely in SNMP for other time-delta calculations. [ROHIT] Agreed. natSessionProtocolType - I don't know why there is a tutorial contained in the description clause; how does this relate to this mib? [ROHIT] wil remove this. natSessionxxxxPort - could InetPortNumber be used here? [ROHIT] Will do that. Would the private and public addresses in the session table be accurately described as local and global addresses, as used in the address map tables, and so on? There should be consistency in naming. [ROHIT] You have a point here. The session table is about addresses and ports, therefore the names of the objects should've used Local and Global - not Private and Public. natSessionCurrentIdleTime - as discussed above, this might be better as a timestamp showing when a packet was last detected. [ROHIT] will take care of this. xxxSecondBindId - as mentioned above, it is better to not specify the error code. [ROHIT] will do . natProtocolStatsName - this is a protocoltype, not a name; why not call it natProtocolStatsProtocol? [ROHIT] will do. natAddrMapStatsAddrUsed - for static assignments, shouldn't the number be one? [ROHIT] The address map may have more than one address, even for a static map. This number should be equal to the number of addresses defined in the address map, for the case of static maps. natInterfaceStatsEntry - wouldn't it be useful to know how many were not translated? [ROHIT] natProtocolStatsRejectCount should take care of this. natAddressUseRising - wouldn't this aalso be useful when an operator added so many static entries that it exceeded the threshold? [ROHIT] static entries are not assigned from the pool; so this notification will not make sense for static entries. natPacketDiscard - shouldn't there be an object to specify the suppression time interval? It could default to 5 seconds, but be configurable by the administrator. [ROHIT] aill add the additional object. The compliance statements have lots of optional objects. If they are important, they shouldn't be optional. If they aren't important, they shouldn't be in the mib. [ROHIT] Many vendors scenario/implementation just suuports the base nat and may not be able to support the optional objects and still be compliant with the MIB. The boilerplates for section 2 and section 7 have changed; the document should be updated accordingly. SNMPv3 RFCs have been renumbered (when they were advanced); the references should be updated. [ROHIT] will do that. Thanks for your comments and we will come back to you with these comments incorporated. Rohit _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From mailnull@www1.ietf.org Thu Feb 6 22:19:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14137 for ; Thu, 6 Feb 2003 22:19:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h173QEC20847 for nat-archive@odin.ietf.org; Thu, 6 Feb 2003 22:26:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h173Jnp20692; Thu, 6 Feb 2003 22:19:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U8jFJ13834 for ; Thu, 30 Jan 2003 03:45:15 -0500 Received: from internetseer.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22084 for ; Thu, 30 Jan 2003 03:22:54 -0500 (EST) Received: (qmail 27575 invoked from network); 30 Jan 2003 08:22:46 -0000 Received: from unknown (HELO pm68) (66.150.40.68) by 0 with SMTP; 30 Jan 2003 08:22:46 -0000 Message-ID: <584925.1043914967339.JavaMail.promon@pm68> Date: Thu, 30 Jan 2003 03:22:47 -0500 (EST) From: Kathy Bradley Reply-To: Kathy Bradley To: nat@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2381_477619.1043914967339" Subject: [NAT] Broken Link On www1.ietf.org Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , ------=_Part_2381_477619.1043914967339 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit There appears to be a problem on this page: http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00205.html When you click on your link to: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-02.txt you get the error: 404 File not found We last last examined your page on Thu Jan 30, 2003 at 03:24:34 AM EST. If your page has not been updated since Thu Jan 30, 2003 at 03:24:34 AM EST, this link is most likely currently broken. As recommended by the Robot Guidelines, this email is to explain our system and to let you know about the broken link on your site. InternetSeer is the largest FREE web site monitoring company in the world, monitoring over 1.1 million web sites worldwide every hour. The error listed above was initially detected by our primary site monitor in Philadelphia, Pa. then verified by our secondary site monitor located in Los Angeles, Ca. If you find this information helpful and would like to receive alerts as soon as we detect an error accessing your site, click here for instant signup. http://scclick.internetseer.com/sitecheck/clickthrough.jsp?I5s57i5f5o5i5d5l5h53M5pI_Ts8g5tSVPX5aNPD53U5pXTxy5p5b5cKTU5dXRTR5bwwM5eXITVzyVP5c_z_RPW5bVP6tDT59LMxD5cH6uT59I_xHS6u5a5f5e5bTUP55x5q5i=e3 As part of your free web site monitoring service, you'll receive immediate notifications when we encounter problems accessing your web site and weekly performance reports. There is no need to cancel because InternetSeer will never contact you again at this email address: nat@ietf.org. If you have other email addresses that you would like excluded from potential future contact, click here to have those email addresses excluded from our system. http://scclick.internetseer.com/sitecheck/cancelemails.jsp InternetSeer does not store or publish the content of your pages, but rather uses availability and link information for our research. Click here to learn more about InternetSeer. http://scclick.internetseer.com/sitecheck/clickthrough.jsp?I5s57i5f5o5i5d5l5h53M5pI_Jurg5tSVPX5aNPD53U5pXTxy5p5b5cKTU5g5aLMxD5dIzL5bH_XC5c6tzRMLJV5cKIzHXIL59MPIWzz5cy6tP5e6vWPwRyx5cNzM5f5c5f5f5h5bQxHI52P5s5e=e3 Sincerely, Kathy Bradley Web Site Analyst InternetSeer.com http://www.internetseer.com/ep/setoc?NR5p764lad5aP5q5eMNNV5cSHVMU5bGxy=e3 -------------------------------------------------------------------------------- As stated above, there is no need to cancel since YOU WILL NEVER be contacted again at nat@ietf.org, but you may click here for a removal confirmation from our web site. ##nat@ietf.org## SRC=52 ------=_Part_2381_477619.1043914967339 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Broken Link On www1.ietf.org There appears to be a problem on this page: http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00205.html
When you click on your link to: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-02.txt
you get the error: 404 File not found

We last last examined your page on Thu Jan 30, 2003 at 03:24:34 AM EST. If your page has not been updated since Thu Jan 30, 2003 at 03:24:34 AM EST, this link is most likely currently broken.

As recommended by the Robot Guidelines, this email is to explain our system and to let you know about the broken link on your site.

InternetSeer is the largest FREE web site monitoring company in the world, monitoring over 1.1 million web sites worldwide every hour.

The error listed above was initially detected by our primary site monitor in Philadelphia, Pa. then verified by our secondary site monitor located in Los Angeles, Ca. before this error event was recorded.

If you find this information helpful and would like to receive alerts as soon as we detect an error accessing your site, click here for instant signup. Remember, our service is free.

As part of your free web site monitoring service, you'll receive immediate notifications when we encounter problems accessing your web site and weekly performance reports.

There is no need to cancel because InternetSeer will never contact you again at this email address: nat@ietf.org. If you have other email addresses that you would like excluded from any potential future contact, click here to have those email addresses excluded from our system.

InternetSeer does not store or publish the content of your pages, but rather uses availability and link information for our research.

Click here to learn more about InternetSeer.

Sincerely,

Kathy Bradley
Web Site Analyst
InternetSeer.com

As stated above, there is no need to cancel since YOU WILL NEVER be contacted again at nat@ietf.org, but you may click here for a removal confirmation from our web site.
##nat@ietf.org## SRC=52 ------=_Part_2381_477619.1043914967339-- _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From nat-admin@ietf.org Thu Feb 6 23:10:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14136 for ; Thu, 6 Feb 2003 22:19:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h173Jnp20692; Thu, 6 Feb 2003 22:19:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U8jFJ13834 for ; Thu, 30 Jan 2003 03:45:15 -0500 Received: from internetseer.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22084 for ; Thu, 30 Jan 2003 03:22:54 -0500 (EST) Received: (qmail 27575 invoked from network); 30 Jan 2003 08:22:46 -0000 Received: from unknown (HELO pm68) (66.150.40.68) by 0 with SMTP; 30 Jan 2003 08:22:46 -0000 Message-ID: <584925.1043914967339.JavaMail.promon@pm68> Date: Thu, 30 Jan 2003 03:22:47 -0500 (EST) From: Kathy Bradley Reply-To: Kathy Bradley To: nat@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2381_477619.1043914967339" Subject: [NAT] Broken Link On www1.ietf.org Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , ------=_Part_2381_477619.1043914967339 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit There appears to be a problem on this page: http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00205.html When you click on your link to: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-02.txt you get the error: 404 File not found We last last examined your page on Thu Jan 30, 2003 at 03:24:34 AM EST. If your page has not been updated since Thu Jan 30, 2003 at 03:24:34 AM EST, this link is most likely currently broken. As recommended by the Robot Guidelines, this email is to explain our system and to let you know about the broken link on your site. InternetSeer is the largest FREE web site monitoring company in the world, monitoring over 1.1 million web sites worldwide every hour. The error listed above was initially detected by our primary site monitor in Philadelphia, Pa. then verified by our secondary site monitor located in Los Angeles, Ca. If you find this information helpful and would like to receive alerts as soon as we detect an error accessing your site, click here for instant signup. http://scclick.internetseer.com/sitecheck/clickthrough.jsp?I5s57i5f5o5i5d5l5h53M5pI_Ts8g5tSVPX5aNPD53U5pXTxy5p5b5cKTU5dXRTR5bwwM5eXITVzyVP5c_z_RPW5bVP6tDT59LMxD5cH6uT59I_xHS6u5a5f5e5bTUP55x5q5i=e3 As part of your free web site monitoring service, you'll receive immediate notifications when we encounter problems accessing your web site and weekly performance reports. There is no need to cancel because InternetSeer will never contact you again at this email address: nat@ietf.org. If you have other email addresses that you would like excluded from potential future contact, click here to have those email addresses excluded from our system. http://scclick.internetseer.com/sitecheck/cancelemails.jsp InternetSeer does not store or publish the content of your pages, but rather uses availability and link information for our research. Click here to learn more about InternetSeer. http://scclick.internetseer.com/sitecheck/clickthrough.jsp?I5s57i5f5o5i5d5l5h53M5pI_Jurg5tSVPX5aNPD53U5pXTxy5p5b5cKTU5g5aLMxD5dIzL5bH_XC5c6tzRMLJV5cKIzHXIL59MPIWzz5cy6tP5e6vWPwRyx5cNzM5f5c5f5f5h5bQxHI52P5s5e=e3 Sincerely, Kathy Bradley Web Site Analyst InternetSeer.com http://www.internetseer.com/ep/setoc?NR5p764lad5aP5q5eMNNV5cSHVMU5bGxy=e3 -------------------------------------------------------------------------------- As stated above, there is no need to cancel since YOU WILL NEVER be contacted again at nat@ietf.org, but you may click here for a removal confirmation from our web site. ##nat@ietf.org## SRC=52 ------=_Part_2381_477619.1043914967339 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Broken Link On www1.ietf.org There appears to be a problem on this page: http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00205.html
When you click on your link to: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-02.txt
you get the error: 404 File not found

We last last examined your page on Thu Jan 30, 2003 at 03:24:34 AM EST. If your page has not been updated since Thu Jan 30, 2003 at 03:24:34 AM EST, this link is most likely currently broken.

As recommended by the Robot Guidelines, this email is to explain our system and to let you know about the broken link on your site.

InternetSeer is the largest FREE web site monitoring company in the world, monitoring over 1.1 million web sites worldwide every hour.

The error listed above was initially detected by our primary site monitor in Philadelphia, Pa. then verified by our secondary site monitor located in Los Angeles, Ca. before this error event was recorded.

If you find this information helpful and would like to receive alerts as soon as we detect an error accessing your site, click here for instant signup. Remember, our service is free.

As part of your free web site monitoring service, you'll receive immediate notifications when we encounter problems accessing your web site and weekly performance reports.

There is no need to cancel because InternetSeer will never contact you again at this email address: nat@ietf.org. If you have other email addresses that you would like excluded from any potential future contact, click here to have those email addresses excluded from our system.

InternetSeer does not store or publish the content of your pages, but rather uses availability and link information for our research.

Click here to learn more about InternetSeer.

Sincerely,

Kathy Bradley
Web Site Analyst
InternetSeer.com

As stated above, there is no need to cancel since YOU WILL NEVER be contacted again at nat@ietf.org, but you may click here for a removal confirmation from our web site.
##nat@ietf.org## SRC=52 ------=_Part_2381_477619.1043914967339-- _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From nat-admin@ietf.org Fri Feb 7 08:17:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09156 for ; Fri, 7 Feb 2003 08:17:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DL8p02222; Fri, 7 Feb 2003 08:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DIWp02111 for ; Fri, 7 Feb 2003 08:18:32 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09058 for ; Fri, 7 Feb 2003 08:11:05 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h17DEeB27226 for ; Fri, 7 Feb 2003 08:14:41 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Feb 2003 14:14:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155D6CDEB@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kathy Bradley , nat@ietf.org Subject: RE: [NAT] Broken Link On www1.ietf.org Date: Fri, 7 Feb 2003 14:14:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Well, that email says that the file is not available. SO the email text and the actual sitiation/reality are in sync ;-) The latest version is: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-05.txt Hope this helps, Bert -----Original Message----- From: Kathy Bradley [mailto:kathy.bradley@mail.internetseer.com] Sent: donderdag 30 januari 2003 9:23 To: nat@ietf.org Subject: [NAT] Broken Link On www1.ietf.org There appears to be a problem on this page: http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00205.html When you click on your link to: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-02.txt you get the error: 404 File not found We last last examined your page on Thu Jan 30, 2003 at 03:24:34 AM EST. If your page has not been updated since Thu Jan 30, 2003 at 03:24:34 AM EST, this link is most likely currently broken. As recommended by the Robot Guidelines, this email is to explain our system and to let you know about the broken link on your site. InternetSeer is the largest FREE web site monitoring company in the world, monitoring over 1.1 million web sites worldwide every hour. The error listed above was initially detected by our primary site monitor in Philadelphia, Pa. then verified by our secondary site monitor located in Los Angeles, Ca. before this error event was recorded. If you find this information helpful and would like to receive alerts as soon as we detect an error accessing your site, click here for instant signup. Remember, our service is free. As part of your free web site monitoring service, you'll receive immediate notifications when we encounter problems accessing your web site and weekly performance reports. There is no need to cancel because InternetSeer will never contact you again at this email address: nat@ietf.org. If you have other email addresses that you would like excluded from any potential future contact, click here to have those email addresses excluded from our system. InternetSeer does not store or publish the content of your pages, but rather uses availability and link information for our research. Click here to learn more about InternetSeer. Sincerely, Kathy Bradley Web Site Analyst InternetSeer.com As stated above, there is no need to cancel since YOU WILL NEVER be contacted again at nat@ietf.org, but you may click here for a removal confirmation from our web site. ##nat@ietf.org## SRC=52 _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From mailnull@www1.ietf.org Fri Feb 7 08:19:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09238 for ; Fri, 7 Feb 2003 08:19:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17DQ9q02378 for nat-archive@odin.ietf.org; Fri, 7 Feb 2003 08:26:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DL8p02222; Fri, 7 Feb 2003 08:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DIWp02111 for ; Fri, 7 Feb 2003 08:18:32 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09058 for ; Fri, 7 Feb 2003 08:11:05 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h17DEeB27226 for ; Fri, 7 Feb 2003 08:14:41 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Feb 2003 14:14:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155D6CDEB@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kathy Bradley , nat@ietf.org Subject: RE: [NAT] Broken Link On www1.ietf.org Date: Fri, 7 Feb 2003 14:14:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Well, that email says that the file is not available. SO the email text and the actual sitiation/reality are in sync ;-) The latest version is: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-05.txt Hope this helps, Bert -----Original Message----- From: Kathy Bradley [mailto:kathy.bradley@mail.internetseer.com] Sent: donderdag 30 januari 2003 9:23 To: nat@ietf.org Subject: [NAT] Broken Link On www1.ietf.org There appears to be a problem on this page: http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00205.html When you click on your link to: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-02.txt you get the error: 404 File not found We last last examined your page on Thu Jan 30, 2003 at 03:24:34 AM EST. If your page has not been updated since Thu Jan 30, 2003 at 03:24:34 AM EST, this link is most likely currently broken. As recommended by the Robot Guidelines, this email is to explain our system and to let you know about the broken link on your site. InternetSeer is the largest FREE web site monitoring company in the world, monitoring over 1.1 million web sites worldwide every hour. The error listed above was initially detected by our primary site monitor in Philadelphia, Pa. then verified by our secondary site monitor located in Los Angeles, Ca. before this error event was recorded. If you find this information helpful and would like to receive alerts as soon as we detect an error accessing your site, click here for instant signup. Remember, our service is free. As part of your free web site monitoring service, you'll receive immediate notifications when we encounter problems accessing your web site and weekly performance reports. There is no need to cancel because InternetSeer will never contact you again at this email address: nat@ietf.org. If you have other email addresses that you would like excluded from any potential future contact, click here to have those email addresses excluded from our system. InternetSeer does not store or publish the content of your pages, but rather uses availability and link information for our research. Click here to learn more about InternetSeer. Sincerely, Kathy Bradley Web Site Analyst InternetSeer.com As stated above, there is no need to cancel since YOU WILL NEVER be contacted again at nat@ietf.org, but you may click here for a removal confirmation from our web site. ##nat@ietf.org## SRC=52 _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat