From mailnull@www1.ietf.org Mon Feb 3 08:54: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 IAA07757 for ; Mon, 3 Feb 2003 08:54:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Dxqi23098 for midcom-archive@odin.ietf.org; Mon, 3 Feb 2003 08:59:52 -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 h13Dx6J23064; Mon, 3 Feb 2003 08:59:06 -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 h12LqgJ24804 for ; Sun, 2 Feb 2003 16:52:42 -0500 Received: from c000.snv.cp.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12403 for ; Sun, 2 Feb 2003 16:47:30 -0500 (EST) Received: (cpmta 15619 invoked from network); 2 Feb 2003 13:51:06 -0800 Received: from 128.84.99.231 (HELO CUCSLOAN170) by smtp.francis.com (209.228.32.71) with SMTP; 2 Feb 2003 13:51:06 -0800 X-Sent: 2 Feb 2003 21:51:06 GMT Message-ID: <004901c2cb05$2d5f98f0$e7635480@cs.cornell.edu> From: "Paul Francis" To: Date: Sun, 2 Feb 2003 16:50:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Subject: [midcom] stun implementations? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm looking for STUN client and server implementations that I can use for a class project. They don't need to be the latest spec (i.e. don't need security), and they don't need to interoperate with anything but each other. Any suggestions? Thanks, PF _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Feb 3 16:36:27 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 QAA22559 for ; Mon, 3 Feb 2003 16:36:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13LfaF27909 for midcom-archive@odin.ietf.org; Mon, 3 Feb 2003 16:41:36 -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 h13LedJ27876; Mon, 3 Feb 2003 16:40:39 -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 h13LdNJ27799 for ; Mon, 3 Feb 2003 16:39:23 -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 QAA22501 for ; Mon, 3 Feb 2003 16:33:42 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id QAA01757 for ; Mon, 3 Feb 2003 16:49:56 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma001743; Mon, 3 Feb 03 16:49:12 -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 16:37:09 -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 16:37:09 -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 16:37:08 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4893A9@NHROCMBX1.ets.enterasys.com> Thread-Topic: NAT MIB Thread-Index: AcLLzEqaQmZa5Ax+Q6upHoTKLcOO0A== From: "Harrington, David" To: "Midcom (E-mail)" X-OriginalArrivalTime: 03 Feb 2003 21:37:09.0272 (UTC) FILETIME=[67A97180:01C2CBCC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h13LdNJ27800 Subject: [midcom] NAT MIB Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 From mailnull@www1.ietf.org Mon Feb 3 16:39: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 QAA22648 for ; Mon, 3 Feb 2003 16:39:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13LiMD28053 for midcom-archive@odin.ietf.org; Mon, 3 Feb 2003 16:44:22 -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 h13Li3J28007; Mon, 3 Feb 2003 16:44:03 -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 h13LhYJ27980 for ; Mon, 3 Feb 2003 16:43:34 -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 QAA22583 for ; Mon, 3 Feb 2003 16:37:53 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id QAA02034 for ; Mon, 3 Feb 2003 16:54:06 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma002002; Mon, 3 Feb 03 16:53:35 -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 16:41:27 -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 16:41:27 -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" Subject: RE: [midcom] It's that time - wg agenda Date: Mon, 3 Feb 2003 16:41:26 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA602F5C@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] It's that time - wg agenda Thread-Index: AcLJVR8DHBUu5SeSRK+4NGXeD88C/QCd3R/Q From: "Harrington, David" To: "Melinda Shore" , X-OriginalArrivalTime: 03 Feb 2003 21:41:27.0210 (UTC) FILETIME=[0167A8A0:01C2CBCD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h13LhYJ27981 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, As we work to design a solution to meet the semantic requirements, I think we are likely to find some issues with the existing document. I suggest it would be better to wait until we have gotten further along on the design team work before going to WG last call on the semantic requirements. dbh > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Friday, January 31, 2003 1:13 PM > To: midcom@ietf.org > Subject: [midcom] It's that time - wg agenda > > > It's time to start thinking about the agenda for the March > meeting in San Francisco. I've once again requested a one > hour slot. The two items we know about, aside from > administrivia, are 1) the semantics document - any > outstanding issues before going to WG last call, and 2) mibs > update. Is there anything else? > > Thanks, > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Feb 13 15:50:32 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 PAA29484 for ; Thu, 13 Feb 2003 15:50:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DKroj19195 for midcom-archive@odin.ietf.org; Thu, 13 Feb 2003 15:53:50 -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 h1DKqcp19113; Thu, 13 Feb 2003 15:52: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 h1DJK1p12539 for ; Thu, 13 Feb 2003 14:20:01 -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 OAA22556 for ; Thu, 13 Feb 2003 14:16:11 -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" Date: Thu, 13 Feb 2003 11:19:55 -0800 Message-ID: <4E9A9436C008314EAA32033B23E96FD9187C62@thorondor.wwp.com> Thread-Topic: NAT MIB Thread-Index: AcLLzEqaQmZa5Ax+Q6upHoTKLcOO0AAA8GAQADFq9uABv2uTAA== From: "Rohit Rohit" To: Cc: , "wang cliff" , "Rajiv Raghunarayan" , "Nalinaksh Pai" , "Rohit Rohit" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1DJK1p12542 Subject: [midcom] FW: [NAT] NAT MIB Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, I am forwarding the response for the David's Comments to the MIDCOM group for further comments. We definitely need feedback on whether the NAT MIB just need to support TCP, UDP and ICMP protocols; or we need to add the provision for the protocol extensibility. IMHO, adding protocol extensibility makes MIB more complex and we gain very little from this. Thanks Rohit -----Original Message----- From: Rohit Rohit Sent: Thursday, February 06, 2003 7:04 PM To: 'Harrington, David'; nat@ietf.org Subject: RE: [NAT] NAT MIB 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Feb 14 03:22:44 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 DAA13413 for ; Fri, 14 Feb 2003 03:22:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1E8QGP05553 for midcom-archive@odin.ietf.org; Fri, 14 Feb 2003 03:26:16 -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 h1E8POp05514; Fri, 14 Feb 2003 03:25:24 -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 h1E8OEp05449 for ; Fri, 14 Feb 2003 03:24:14 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13389 for ; Fri, 14 Feb 2003 03:20:08 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1E8NAR58748; Fri, 14 Feb 2003 09:23:10 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EF44587947; Fri, 14 Feb 2003 09:22:38 +0100 (CET) Message-ID: <3E4CA6F6.5020100@ccrle.nec.de> Date: Fri, 14 Feb 2003 09:21:10 +0100 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohit Rohit Cc: midcom@ietf.org, srisuresh@yahoo.com, wang cliff , Rajiv Raghunarayan , Nalinaksh Pai Subject: Re: [midcom] FW: [NAT] NAT MIB References: <4E9A9436C008314EAA32033B23E96FD9187C62@thorondor.wwp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, the protocols TCP, UDP and ICMP are fine. How about IP itself? The semantics talk about TCP, UDP and IP and don't talk about ICMP. So TCP,UDP and IP would be fine to have. Martin Rohit Rohit wrote: > Hi, > > I am forwarding the response for the David's Comments to the MIDCOM group > for further comments. > We definitely need feedback on whether the NAT MIB just need to support > TCP, UDP and ICMP protocols; or we need to add the provision for the protocol > extensibility. IMHO, adding protocol extensibility makes MIB more complex > and we gain very little from this. > > > Thanks > Rohit > > -----Original Message----- > From: Rohit Rohit > Sent: Thursday, February 06, 2003 7:04 PM > To: 'Harrington, David'; nat@ietf.org > Subject: RE: [NAT] NAT MIB > > > 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 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Feb 14 10:27: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 KAA24643 for ; Fri, 14 Feb 2003 10:26:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EFUcG00815 for midcom-archive@odin.ietf.org; Fri, 14 Feb 2003 10:30:38 -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 h1EFQSp00642; Fri, 14 Feb 2003 10:26:28 -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 h1EFOxp00566 for ; Fri, 14 Feb 2003 10:24:59 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24456 for ; Fri, 14 Feb 2003 10:20:44 -0500 (EST) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HAB0074H1CM4V@firewall.wcom.com> for midcom@ietf.org; Fri, 14 Feb 2003 15:22:04 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAB0090114TZA@pmismtp04.wcomnet.com>; Fri, 14 Feb 2003 15:21:58 +0000 (GMT) Received: from ws041v4569 ([166.35.241.24]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAB00A0Z1C8FR@pmismtp04.wcomnet.com>; Fri, 14 Feb 2003 15:21:45 +0000 (GMT) Date: Fri, 14 Feb 2003 09:21:41 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] FW: [NAT] NAT MIB In-reply-to: <3E4CA6F6.5020100@ccrle.nec.de> To: "'Martin Stiemerling'" , "'Rohit Rohit'" Cc: midcom@ietf.org, srisuresh@yahoo.com, "'wang cliff'" , "'Rajiv Raghunarayan'" , "'Nalinaksh Pai'" Message-id: <003701c2d43c$c6d1f510$0a00a8c0@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Also IPSec ESP/AH (These are part of IP, just want to make sure it is considered if necessary). -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Martin Stiemerling Sent: Friday, February 14, 2003 2:21 AM To: Rohit Rohit Cc: midcom@ietf.org; srisuresh@yahoo.com; wang cliff; Rajiv Raghunarayan; Nalinaksh Pai Subject: Re: [midcom] FW: [NAT] NAT MIB Hi, the protocols TCP, UDP and ICMP are fine. How about IP itself? The semantics talk about TCP, UDP and IP and don't talk about ICMP. So TCP,UDP and IP would be fine to have. Martin Rohit Rohit wrote: > Hi, > > I am forwarding the response for the David's Comments to the MIDCOM > group for further comments. We definitely need feedback on whether the > NAT MIB just need to support TCP, UDP and ICMP protocols; or we need > to add the provision for the protocol extensibility. IMHO, adding > protocol extensibility makes MIB more complex and we gain very little > from this. > > > Thanks > Rohit > > -----Original Message----- > From: Rohit Rohit > Sent: Thursday, February 06, 2003 7:04 PM > To: 'Harrington, David'; nat@ietf.org > Subject: RE: [NAT] NAT MIB > > > 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 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Feb 14 14:02:46 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 OAA01295 for ; Fri, 14 Feb 2003 14:02:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EJ6WU16179 for midcom-archive@odin.ietf.org; Fri, 14 Feb 2003 14:06:32 -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 h1EJ5lp16146; Fri, 14 Feb 2003 14:05:47 -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 h1EJ48p16058 for ; Fri, 14 Feb 2003 14:04:08 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01169 for ; Fri, 14 Feb 2003 13:59:52 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1EJ2qD18783; Fri, 14 Feb 2003 14:02:55 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15KGW2D0; Fri, 14 Feb 2003 14:02:53 -0500 Received: from nortelnetworks.com (acart1cg.ca.nortel.com [47.129.129.59]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NC2Q6; Fri, 14 Feb 2003 14:02:52 -0500 Message-ID: <3E4D3D58.4030901@nortelnetworks.com> Date: Fri, 14 Feb 2003 14:02:48 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Rohit Rohit CC: srisuresh@yahoo.com, wang cliff , Rajiv Raghunarayan , Nalinaksh Pai , midcom@ietf.org Subject: Re: [midcom] FW: [NAT] NAT MIB References: <4E9A9436C008314EAA32033B23E96FD9187C62@thorondor.wwp.com> In-Reply-To: <4E9A9436C008314EAA32033B23E96FD9187C62@thorondor.wwp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Could I put a word in for SCTP on that list of protocols? Rohit Rohit wrote: > Hi, > > I am forwarding the response for the David's Comments to the MIDCOM group > for further comments. > We definitely need feedback on whether the NAT MIB just need to support > TCP, UDP and ICMP protocols; or we need to add the provision for the protocol > extensibility. IMHO, adding protocol extensibility makes MIB more complex > and we gain very little from this. > [snip] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Feb 15 13:07:42 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 NAA05673 for ; Sat, 15 Feb 2003 13:07:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FIBut06154 for midcom-archive@odin.ietf.org; Sat, 15 Feb 2003 13:11:56 -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 h1FIBOp06134; Sat, 15 Feb 2003 13:11:24 -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 h1FI9bp06083 for ; Sat, 15 Feb 2003 13:09:37 -0500 Received: from smtp011.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05642 for ; Sat, 15 Feb 2003 13:04:51 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Feb 2003 18:08:38 -0000 Reply-To: From: "Pyda Srisuresh" To: "Martin Stiemerling" , "Rohit Rohit" Cc: , "wang cliff" , "Rajiv Raghunarayan" , "Nalinaksh Pai" Subject: RE: [midcom] FW: [NAT] NAT MIB Date: Sat, 15 Feb 2003 10:08:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E4CA6F6.5020100@ccrle.nec.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Martin, Please see my comments in-line. regards, suresh > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Friday, February 14, 2003 12:21 AM > To: Rohit Rohit > Cc: midcom@ietf.org; srisuresh@yahoo.com; wang cliff; Rajiv > Raghunarayan; Nalinaksh Pai > Subject: Re: [midcom] FW: [NAT] NAT MIB > > > Hi, > > the protocols TCP, UDP and ICMP are fine. How about IP itself? The I assume, you are refering to Basic-NAT. The description for the fields natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom, and natConfGlobalPortTo do state that they should be 0 for Basic-NAT address mapping. > semantics talk about TCP, UDP and IP and don't talk about ICMP. So You are right. We did not state the interpretation of these fields for ICMP packets. We will include the text for ICMP (as described in RFC 3022) in the next rev. > TCP,UDP and IP would be fine to have. > > Martin > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Feb 15 14:01:18 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 OAA06363 for ; Sat, 15 Feb 2003 14:01:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FJ5WS08216 for midcom-archive@odin.ietf.org; Sat, 15 Feb 2003 14:05:32 -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 h1FJ58p08200; Sat, 15 Feb 2003 14:05: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 h1FJ4np08172 for ; Sat, 15 Feb 2003 14:04:49 -0500 Received: from smtp015.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06347 for ; Sat, 15 Feb 2003 14:00:04 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Feb 2003 19:03:49 -0000 Reply-To: From: "Pyda Srisuresh" To: "Christopher A. Martin" , "'Martin Stiemerling'" , "'Rohit Rohit'" Cc: , "'wang cliff'" , "'Rajiv Raghunarayan'" , "'Nalinaksh Pai'" Subject: RE: [midcom] FW: [NAT] NAT MIB Date: Sat, 15 Feb 2003 11:03:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <003701c2d43c$c6d1f510$0a00a8c0@ws041v4569> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Christopher, The NAT-MIB draft is intended for use with just TCP, UDP and ICMP protocols (in the context of NAPT). NAPT behaviour for these protocols is documented in RFC 3022. Having said that, natConfProtocol is BITS type. Any protocol exensions and the corresponding MIB extensions for these protocols should be reviewed independently in seperate docs. IMHO, making protocol extensions to NAT in the NAT-MIB is a slippery slope. cheers, suresh > -----Original Message----- > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > Sent: Friday, February 14, 2003 7:22 AM > To: 'Martin Stiemerling'; 'Rohit Rohit' > Cc: midcom@ietf.org; srisuresh@yahoo.com; 'wang cliff'; 'Rajiv > Raghunarayan'; 'Nalinaksh Pai' > Subject: RE: [midcom] FW: [NAT] NAT MIB > > > Also IPSec ESP/AH (These are part of IP, just want to make sure it is > considered if necessary). > > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of > Martin Stiemerling > Sent: Friday, February 14, 2003 2:21 AM > To: Rohit Rohit > Cc: midcom@ietf.org; srisuresh@yahoo.com; wang cliff; Rajiv > Raghunarayan; Nalinaksh Pai > Subject: Re: [midcom] FW: [NAT] NAT MIB > > > Hi, > > the protocols TCP, UDP and ICMP are fine. How about IP itself? The > semantics talk about TCP, UDP and IP and don't talk about ICMP. So > TCP,UDP and IP would be fine to have. > > Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Feb 15 14:21:24 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 OAA06516 for ; Sat, 15 Feb 2003 14:21:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FJPdE09386 for midcom-archive@odin.ietf.org; Sat, 15 Feb 2003 14:25:39 -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 h1FJPFp09369; Sat, 15 Feb 2003 14:25:15 -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 h1FJO6p09323 for ; Sat, 15 Feb 2003 14:24:06 -0500 Received: from smtp011.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06501 for ; Sat, 15 Feb 2003 14:19:20 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Feb 2003 19:23:05 -0000 Reply-To: From: "Pyda Srisuresh" To: "Tom Taylor" , "Rohit Rohit" Cc: "wang cliff" , "Rajiv Raghunarayan" , "Nalinaksh Pai" , Subject: RE: [midcom] FW: [NAT] NAT MIB Date: Sat, 15 Feb 2003 11:22:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E4D3D58.4030901@nortelnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Tom, How is NAPT expected to function with SCTP (say, as different from TCP)? As I mentioned earlier (in reponse to Christopher), I believe, protocol extensions (outside of TCP, UDP and ICMP) should be considered independently in an extensions document. cheers, suresh > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Tom Taylor > Sent: Friday, February 14, 2003 11:03 AM > To: Rohit Rohit > Cc: srisuresh@yahoo.com; wang cliff; Rajiv Raghunarayan; Nalinaksh Pai; > midcom@ietf.org > Subject: Re: [midcom] FW: [NAT] NAT MIB > > > Could I put a word in for SCTP on that list of protocols? > > Rohit Rohit wrote: > > Hi, > > > > I am forwarding the response for the David's Comments to the > MIDCOM group > > for further comments. > > We definitely need feedback on whether the NAT MIB just need to support > > TCP, UDP and ICMP protocols; or we need to add the provision > for the protocol > > extensibility. IMHO, adding protocol extensibility makes MIB > more complex > > and we gain very little from this. > > > [snip] > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Feb 19 14:21:15 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 OAA05703 for ; Wed, 19 Feb 2003 14:21:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JJRRp03514 for midcom-archive@odin.ietf.org; Wed, 19 Feb 2003 14:27: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 h1JJQ2p03482; Wed, 19 Feb 2003 14:26:02 -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 h1JJOtp03409 for ; Wed, 19 Feb 2003 14:24:55 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05626 for ; Wed, 19 Feb 2003 14:18:12 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1JJLoB6023046; Wed, 19 Feb 2003 11:21:50 -0800 (PST) Received: from fluffyw2k ([128.107.170.154]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABO78550; Wed, 19 Feb 2003 11:21:59 -0800 (PST) From: "Cullen Jennings" To: "'Tom Taylor'" , Subject: RE: [midcom] FW: [NAT] NAT MIB Date: Wed, 19 Feb 2003 11:21:59 -0800 Message-ID: <004701c2d84c$2ca9e100$9aaa6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E4D3D58.4030901@nortelnetworks.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Agree with Tom on SCCP and we might want to consider DCCP too. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On > Behalf Of Tom Taylor > Sent: Friday, February 14, 2003 11:03 AM > To: Rohit Rohit > Cc: srisuresh@yahoo.com; wang cliff; Rajiv Raghunarayan; > Nalinaksh Pai; midcom@ietf.org > Subject: Re: [midcom] FW: [NAT] NAT MIB > > > Could I put a word in for SCTP on that list of protocols? > > Rohit Rohit wrote: > > Hi, > > > > I am forwarding the response for the David's Comments to the MIDCOM > > group for further comments. We definitely need feedback on > whether the > > NAT MIB just need to support TCP, UDP and ICMP protocols; > or we need > > to add the provision for the protocol extensibility. IMHO, adding > > protocol extensibility makes MIB more complex and we gain > very little > > from this. > > > [snip] > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Feb 20 09:47:24 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 JAA16160 for ; Thu, 20 Feb 2003 09:47:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KEs0017994 for midcom-archive@odin.ietf.org; Thu, 20 Feb 2003 09:54:00 -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 h1KErSp17940; Thu, 20 Feb 2003 09:53:28 -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 h1KEonp17808 for ; Thu, 20 Feb 2003 09:50:49 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16076 for ; Thu, 20 Feb 2003 09:43:41 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1KEl1V07222; Thu, 20 Feb 2003 09:47:01 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FGRXJ3NR; Thu, 20 Feb 2003 09:47:01 -0500 Received: from nortelnetworks.com (acart1be.ca.nortel.com [47.129.129.24]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1901L0M1; Thu, 20 Feb 2003 09:47:01 -0500 Message-ID: <3E54EA5B.1060401@nortelnetworks.com> Date: Thu, 20 Feb 2003 09:46:51 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: srisuresh@yahoo.com CC: "Tom-PT Taylor" , Rohit Rohit , wang cliff , Rajiv Raghunarayan , Nalinaksh Pai , midcom@ietf.org Subject: Re: [midcom] FW: [NAT] NAT MIB References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit SCTP has at least two points of difference from TCP: a different "next protocol" number in the IP header, and the need to map multiple IP addresses in the same association. I assume it's that latter requirement that causes you to recommend that SCTP be dealt with in an extension. I'd have to think about it a bit, but it seems to me possible that most of the difference in treatment would be the responsibility of the Agent rather than the Middlebox. The main change for the latter would be that it would be possible to have multiple policy rules mapping through the same SCTP port. Pyda Srisuresh wrote: > Hi Tom, > > How is NAPT expected to function with SCTP (say, as different > from TCP)? As I mentioned earlier (in reponse to Christopher), > I believe, protocol extensions (outside of TCP, UDP and ICMP) > should be considered independently in an extensions document. > > cheers, > suresh > > >>-----Original Message----- >>From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of >>Tom Taylor >>Sent: Friday, February 14, 2003 11:03 AM >>To: Rohit Rohit >>Cc: srisuresh@yahoo.com; wang cliff; Rajiv Raghunarayan; Nalinaksh Pai; >>midcom@ietf.org >>Subject: Re: [midcom] FW: [NAT] NAT MIB >> >> >>Could I put a word in for SCTP on that list of protocols? >> >>Rohit Rohit wrote: >> >>>Hi, >>> >>>I am forwarding the response for the David's Comments to the >> >>MIDCOM group >> >>>for further comments. >>>We definitely need feedback on whether the NAT MIB just need to support >>>TCP, UDP and ICMP protocols; or we need to add the provision >> >>for the protocol >> >>>extensibility. IMHO, adding protocol extensibility makes MIB >> >>more complex >> >>>and we gain very little from this. >>> >> >>[snip] >> >>_______________________________________________ >>midcom mailing list >>midcom@ietf.org >>https://www1.ietf.org/mailman/listinfo/midcom > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Feb 24 09:09:45 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 JAA15016 for ; Mon, 24 Feb 2003 09:09:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OEII027712 for midcom-archive@odin.ietf.org; Mon, 24 Feb 2003 09:18:18 -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 h1OEHep27684; Mon, 24 Feb 2003 09:17:40 -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 h1OEG5p27646 for ; Mon, 24 Feb 2003 09:16:05 -0500 Received: from web40412.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14947 for ; Mon, 24 Feb 2003 09:07:01 -0500 (EST) Message-ID: <20030224141054.8366.qmail@web40412.mail.yahoo.com> Received: from [12.234.140.126] by web40412.mail.yahoo.com via HTTP; Mon, 24 Feb 2003 06:10:54 PST Date: Mon, 24 Feb 2003 06:10:54 -0800 (PST) From: Pyda Srisuresh Subject: Re: [midcom] FW: [NAT] NAT MIB To: Tom Taylor Cc: Tom-PT Taylor , Rohit Rohit , wang cliff , Rajiv Raghunarayan , Nalinaksh Pai , midcom@ietf.org In-Reply-To: <3E54EA5B.1060401@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Yes. Basically, there has not been a document describing the traversal of SCTP applications via NAT devices. NATMIB draft, I donot believe, is the place to do that. cheers, suresh --- Tom Taylor wrote: > SCTP has at least two points of difference from TCP: a different "next > protocol" > number in the IP header, and the need to map multiple IP addresses in the > same > association. I assume it's that latter requirement that causes you to > recommend > that SCTP be dealt with in an extension. I'd have to think about it a bit, > but it > seems to me possible that most of the difference in treatment would be the > responsibility of the Agent rather than the Middlebox. The main change for > the > latter would be that it would be possible to have multiple policy rules > mapping > through the same SCTP port. > > Pyda Srisuresh wrote: > > Hi Tom, > > > > How is NAPT expected to function with SCTP (say, as different > > from TCP)? As I mentioned earlier (in reponse to Christopher), > > I believe, protocol extensions (outside of TCP, UDP and ICMP) > > should be considered independently in an extensions document. > > > > cheers, > > suresh > > > > > >>-----Original Message----- > >>From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > >>Tom Taylor > >>Sent: Friday, February 14, 2003 11:03 AM > >>To: Rohit Rohit > >>Cc: srisuresh@yahoo.com; wang cliff; Rajiv Raghunarayan; Nalinaksh Pai; > >>midcom@ietf.org > >>Subject: Re: [midcom] FW: [NAT] NAT MIB > >> > >> > >>Could I put a word in for SCTP on that list of protocols? > >> > >>Rohit Rohit wrote: > >> > >>>Hi, > >>> > >>>I am forwarding the response for the David's Comments to the > >> > >>MIDCOM group > >> > >>>for further comments. > >>>We definitely need feedback on whether the NAT MIB just need to support > >>>TCP, UDP and ICMP protocols; or we need to add the provision > >> > >>for the protocol > >> > >>>extensibility. IMHO, adding protocol extensibility makes MIB > >> > >>more complex > >> > >>>and we gain very little from this. > >>> > >> > >>[snip] > >> > >>_______________________________________________ > >>midcom mailing list > >>midcom@ietf.org > >>https://www1.ietf.org/mailman/listinfo/midcom > > > > > > ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Feb 27 17:28:25 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 RAA26409 for ; Thu, 27 Feb 2003 17:28:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RMcZg27926 for midcom-archive@odin.ietf.org; Thu, 27 Feb 2003 17:38:35 -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 h1RMWsp27007; Thu, 27 Feb 2003 17:32:54 -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 h1RMVWp26955 for ; Thu, 27 Feb 2003 17:31:32 -0500 Received: from dnsmx1pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26231 for ; Thu, 27 Feb 2003 17:20:51 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA22800; Thu, 27 Feb 2003 17:23:51 -0500 (EST) To: midcom@ietf.org Cc: petrovic@corp.earthlink.net X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Thu, 27 Feb 2003 17:29:46 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 02/27/2003 05:23:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] STUN ietf-draft 05 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , greetings, Marc Petrovic pointed to me that an early implementation of STUN at ( http://www.columbia.edu/~pt81/cs6901-08/cs6901-08.html) is setting the family field value of a STUN mesage, to 01 instead of 02 (to indicate family IPv4) as it is noted in the the latest STUN draft. Earlier versions of the draft state to set the value to 02 (when using IPv6). Was this intented, and if so, what is the rationale behind it? Peter PS: For those interested, I will be posting a new STUN implementation at the above URL soon after the SIPit event this week. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Feb 27 20:29:29 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 UAA29660 for ; Thu, 27 Feb 2003 20:29:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S1dir05559 for midcom-archive@odin.ietf.org; Thu, 27 Feb 2003 20:39:44 -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 h1S1dIp05550; Thu, 27 Feb 2003 20:39:18 -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 h1S1aDp04729 for ; Thu, 27 Feb 2003 20:36:13 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29575 for ; Thu, 27 Feb 2003 20:25:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1S1TNYH005968; Thu, 27 Feb 2003 20:29:23 -0500 (EST) Message-ID: <3E5EBB6C.1050308@dynamicsoft.com> Date: Thu, 27 Feb 2003 20:29:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Panayiotis A. Thermos" CC: midcom@ietf.org, petrovic@corp.earthlink.net Subject: Re: [midcom] STUN ietf-draft 05 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I wish I had a better answer, but I have no idea why this changed. It could be that it was a copy-paste error that got snuck in when that paragraph was rewritten. STUN is now in auth48, so it is conceivable to change it back, although I am not sure that is the right thing. Can people let me know which value they are using in their implementations today? Thanks, Jonathan R. Panayiotis A. Thermos wrote: > greetings, > > Marc Petrovic pointed to me that an early implementation > of STUN at ( http://www.columbia.edu/~pt81/cs6901-08/cs6901-08.html) > is setting the family field value of a STUN mesage, to 01 instead of 02 > (to indicate family IPv4) as it is noted in the the latest STUN draft. > Earlier versions of the draft state to set the value to 02 (when using > IPv6). > Was this intented, and if so, what is the rationale behind it? > > Peter > > PS: For those interested, I will be posting a new STUN implementation at > the above URL soon after > the SIPit event this week. > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Feb 28 04:16:25 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 EAA18087 for ; Fri, 28 Feb 2003 04:16:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S9QnM10934 for midcom-archive@odin.ietf.org; Fri, 28 Feb 2003 04:26:49 -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 h1S9QKp10914; Fri, 28 Feb 2003 04:26:20 -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 h1S9PJp10866 for ; Fri, 28 Feb 2003 04:25:19 -0500 Received: from hotsip.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18052 for ; Fri, 28 Feb 2003 04:14:25 -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: [midcom] STUN ietf-draft 05 Date: Fri, 28 Feb 2003 10:18:19 +0100 Message-ID: Thread-Topic: [midcom] STUN ietf-draft 05 Thread-Index: AcLeybBNh9VQyhvjQO60L9ij08jsPQAP9UAw From: "Kristoffer Gronowski" To: , "Jonathan Rosenberg" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1S9PJp10867 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We have been testing STUN clients and servers on SipIt in Stockholm this week. The majority used 0x01 for IPv4 so Rohan Mahy suggested that we should report this as a typo. I believe that it would be more people out there that feels the same way. It's not a big problem since one have to redo and check the current implementation when STUN becomes a RFC. But my vote is to change it back to 0x01. //Regards Stoffe! -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: den 28 februari 2003 02:29 To: Panayiotis A. Thermos Cc: midcom@ietf.org; petrovic@corp.earthlink.net Subject: Re: [midcom] STUN ietf-draft 05 I wish I had a better answer, but I have no idea why this changed. It could be that it was a copy-paste error that got snuck in when that paragraph was rewritten. STUN is now in auth48, so it is conceivable to change it back, although I am not sure that is the right thing. Can people let me know which value they are using in their implementations today? Thanks, Jonathan R. Panayiotis A. Thermos wrote: > greetings, > > Marc Petrovic pointed to me that an early implementation > of STUN at ( http://www.columbia.edu/~pt81/cs6901-08/cs6901-08.html) > is setting the family field value of a STUN mesage, to 01 instead of 02 > (to indicate family IPv4) as it is noted in the the latest STUN draft. > Earlier versions of the draft state to set the value to 02 (when using > IPv6). > Was this intented, and if so, what is the rationale behind it? > > Peter > > PS: For those interested, I will be posting a new STUN implementation at > the above URL soon after > the SIPit event this week. > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Feb 28 07:30:49 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 HAA23165 for ; Fri, 28 Feb 2003 07:30:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCfHf23459 for midcom-archive@odin.ietf.org; Fri, 28 Feb 2003 07:41:17 -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 h1SCe2p23310; Fri, 28 Feb 2003 07:40:02 -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 h1SCZsp22257 for ; Fri, 28 Feb 2003 07:35:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22546; Fri, 28 Feb 2003 07:24:55 -0500 (EST) Message-Id: <200302281224.HAA22546@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Feb 2003 07:24:55 -0500 Subject: [midcom] I-D ACTION:draft-mahy-midcom-premidcom-relay-reqs-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Pre-Midcom Requirements for Traversal of NATs for traffic not supported by STUN Author(s) : R. Mahy Filename : draft-mahy-midcom-premidcom-relay-reqs-00.txt Pages : 7 Date : 2003-2-27 STUN (Simple Traversal of UDP for NATS) specifies a mechanism which enables nodes in a private network to determine if they are behind a NAT, to discover their remapped address and port, and for many types of NATs to send UDP traffic through them. In addition TCP connections initiated from the private side of NATs already works. This document specifies requirements for a mechanism that enables traversal of expected TCP traffic through all NATs, and traversal of UDP traffic through symmetric NATs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-midcom-premidcom-relay-reqs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mahy-midcom-premidcom-relay-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mahy-midcom-premidcom-relay-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-midcom-premidcom-relay-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-midcom-premidcom-relay-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132746.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom