Network Working Group A. Persson Internet-Draft SUN Expires: December 17, 2006 P. Schauer A. Durand Comcast June 15, 2006 Issues regarding RFC 4113 and 4022 draft-persson-v6ops-mib-issue-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 17, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In RFC 4113 and 4022 there exists several objects which do not provide sufficient descriptions, which might result in implementations that have different behavior. We provide a short discussion why we think the descriptions are insufficient and how they can be clarified. Persson, et al. Expires December 17, 2006 [Page 1] Internet-Draft Issues regarding RFC 4113 and 4022 June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Suggested Approach . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Persson, et al. Expires December 17, 2006 [Page 2] Internet-Draft Issues regarding RFC 4113 and 4022 June 2006 1. Introduction Between RFC 4113 and 4022 there are several objects have unclear behavior. A clarification is needed in order to guarantee uniform behavior across all entities implementing the RFCs. Specifically, the objects in question are tcpConnectionProcess, tcpListenerProcess, udpEndpointProcess (Process objects) and udpEndpointInstance (Instance object). Persson, et al. Expires December 17, 2006 [Page 3] Internet-Draft Issues regarding RFC 4113 and 4022 June 2006 2. Issues The Process objects are all described as the system process associated with a particular connection/endpoint/listener. A zero value is used to identify cases where no process is associated with the connection. However, the description does not cover environments where it might not be possible to obtain the process that is associated with a connection, or cases where multiple processes share the same connection. A simple example of the latter case would be an application that initially opens a socket, and then use fork() to create a child process, which would create a situation where two processes are associated with a connection. The second issue is udpEndpointInstance, which is part of udpEndpointTable. The table is introduced in RFC 4113 and it contains all connected and listening UDP endpoints. The entries in the table are indexed using the connection tuple as well as the Instance object. The Instance is used to distinguish between multiple identical UDP endpoints, which might happen, for example, if multicast is used. However, the current description is rather vague, and does not specify whether or not the instance values can be reused, nor does it state if the instance values are supposed to be allocated in any particular order. To illustrate the issues, consider the following scenarios: The table initially contains an endpoint with the tuple A and instance x (A.x). The connection is then terminated, and a new identical endpoint is opened, and it is assigned an instance value y. If x and y happen to be identical, then it would be impossible for a manager to know that a change has occurred. If in the above scenario A.x did not close, then the table would contain the two entries A.x and A.y. What is not clear is the relationship between x and y. Should y be larger than x since A.y is newer connection? Persson, et al. Expires December 17, 2006 [Page 4] Internet-Draft Issues regarding RFC 4113 and 4022 June 2006 3. Suggested Approach In its current state, the Process object is of limited use, since it only allows for a single system process to be associated with a connection. A more generic solution could be obtained by deprecating the current Process objects and instead provide a separate table that would associate process id's with connections. If the Process objects are not deprecated we suggest that the following two cases are clarified: 1) A process is available, but the information cannot be provided 2) Multiple processes are associated with one connection We think that a reasonable solution for the first issue would be to extend the definition of zero to include cases where the process is unknown. Although an unknown process is fundamentally different from a situation where a process is not available, this approach only requires a minimal change rather than including additional objects. For the second issue we think that providing a limited set of information is better than no information at all. Therefore, if there are multiple processes associated with a connection, it would be useful if information about any of those processes is reported. In the event that information could not be obtained, the process would be set to zero. For the Instance object to be useful it must be ensured that the value is not reused (or reused very infrequently). The current description does not set any guidelines as to how the instance values can be reused, and may thus vary greatly between implementations. One possible way to generate a more uniform behavior would be to add a time stamp object as an INDEX, and rely on the Instance object only to distinguish identical endpoints that also have the same time stamp. In addition, a time stamp based object would provide managers with useful information (i.e., some information of when the endpoint created). If the above addition is not made, then we suggest the following issues should be clarified: 1) Reuse of Instance values 2) Allocation of Instance values Rather than specifying the minimum reuse frequency, we think that the description should be amended to clearly state that infrequent reuse Persson, et al. Expires December 17, 2006 [Page 5] Internet-Draft Issues regarding RFC 4113 and 4022 June 2006 is preferable, and that care should be taken when implementing the RFC. The other issue that needs to be clarified is whether or not instance values should be allocated in any particular order. We believe that allowing arbitrary assignment provides the person implementing the RFC with maximum flexibility, which in turn could help in providing minimal reuse of the instance values. Persson, et al. Expires December 17, 2006 [Page 6] Internet-Draft Issues regarding RFC 4113 and 4022 June 2006 4. Security Considerations The security considerations specified in RFC 4113 and RFC 4022 applies here. Persson, et al. Expires December 17, 2006 [Page 7] Internet-Draft Issues regarding RFC 4113 and 4022 June 2006 5. IANA Considerations There are no IANA actions requested in this specification. Persson, et al. Expires December 17, 2006 [Page 8] Internet-Draft Issues regarding RFC 4113 and 4022 June 2006 Authors' Addresses Anders Persson SUN Microsystems inc. 17 Network Circle Menlo Park, CA, 94025 USA Email: anders.persson@sun.com Paul Schauer Comcast 183 Inverness Dr West Englewood CO 80112 USA Email: Paul_Schauer@cable.comcast.com Alain Durand Comcast 1500 Market st Philadelphia PA 19102 USA Email: Alain_Durand@cable.comcast.com Persson, et al. Expires December 17, 2006 [Page 9] Internet-Draft Issues regarding RFC 4113 and 4022 June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Persson, et al. Expires December 17, 2006 [Page 10]