idnits 2.17.1 draft-ietf-sigtran-rfc4233update-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 169. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 176. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 182. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4233, updated by this document, for RFC5378 checks: 2003-05-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2007) is 6018 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3057 (Obsoleted by RFC 4233) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft Muenster Univ. of Applied Sciences 4 Updates: 4233 (if approved) K. Morneault 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: May 6, 2008 November 3, 2007 8 TEI Query Request Number Change 9 draft-ietf-sigtran-rfc4233update-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 6, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Integrated Services Digital Network (ISDN) Q.921-User Adaptation 43 Layer (IUA) protocol described in RFC4233 defines the messages type 44 of Terminal Endpoint Identifier (TEI) Query Request messages as 5. 45 But this number is already used by the Digital Private Network 46 Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) 47 Extensions (DUA) to the IUA Protocol described in RFC4129. This 48 document updates RFC4233 such that the message type of TEI Query 49 Request messages is 8. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. New Message Type of the TEI Query Message . . . . . . . . . . . 3 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 3 59 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 61 Intellectual Property and Copyright Statements . . . . . . . . . . 5 63 1. Introduction 65 The Integrated Services Digital Network (ISDN) Q.921-User Adaptation 66 Layer (IUA) protocol described in [RFC3057] does not define a 67 Terminal Endpoint Identifier (TEI) Query Request message. The 68 Digital Private Network Signaling System (DPNSS)/Digital Access 69 Signaling System 2 (DASS 2) Extensions (DUA) to the IUA Protocol 70 described in [RFC4129] introduces Data Link Connection (DLC) Status 71 messages of type 5, 6, and 7. Then [RFC4233] was published, which 72 updates [RFC3057]. [RFC4233] also introduces the TEI Query Request 73 message and uses the message type of 5 for it. This makes it 74 impossible to differentiate the DLC Status request from a TEI Query 75 Request. 77 This document updates [RFC4233]. 79 2. Conventions 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. New Message Type of the TEI Query Message 87 This document updates [RFC4233] by introducing the following change. 89 Terminal Endpoint Identifier (TEI) Query messages MUST be encoded 90 with a message type of 8 instead of 5 as described in [RFC4233]. 92 4. IANA Considerations 94 IANA should reserve the message type 8 of Management Messages for 95 Terminal Endpoint Identifier (TEI) Query Request messages. 97 5. Security Considerations 99 This document does not require any security considerations in 100 addition to the ones given in [RFC4233]. 102 6. Acknowledgments 104 The authors wish to thank Jon Peterson and Christian Vogel for their 105 invaluable comments. 107 7. Normative References 109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 110 Requirement Levels", BCP 14, RFC 2119, March 1997. 112 [RFC3057] Morneault, K., Rengasami, S., Kalla, M., and G. 113 Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057, 114 February 2001. 116 [RFC4129] Mukundan, R., Morneault, K., and N. Mangalpally, "Digital 117 Private Network Signaling System (DPNSS)/Digital Access 118 Signaling System 2 (DASS 2) Extensions to the IUA 119 Protocol", RFC 4129, September 2005. 121 [RFC4233] Morneault, K., Rengasami, S., Kalla, M., and G. 122 Sidebottom, "Integrated Services Digital Network (ISDN) 123 Q.921-User Adaptation Layer", RFC 4233, January 2006. 125 Authors' Addresses 127 Michael Tuexen 128 Muenster Univ. of Applied Sciences 129 Stegerwaldstr. 39 130 48565 Steinfurt 131 Germany 133 Email: tuexen@fh-muenster.de 135 Ken Morneault 136 Cisco Systems, Inc. 137 13615 Dulles Technology Drive 138 Herndon, VA 20171 139 US 141 Phone: +1-703-484-3323 142 Email: kmorneau@cisco.com 144 Full Copyright Statement 146 Copyright (C) The IETF Trust (2007). 148 This document is subject to the rights, licenses and restrictions 149 contained in BCP 78, and except as set forth therein, the authors 150 retain all their rights. 152 This document and the information contained herein are provided on an 153 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 154 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 155 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 156 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 157 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 158 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 160 Intellectual Property 162 The IETF takes no position regarding the validity or scope of any 163 Intellectual Property Rights or other rights that might be claimed to 164 pertain to the implementation or use of the technology described in 165 this document or the extent to which any license under such rights 166 might or might not be available; nor does it represent that it has 167 made any independent effort to identify any such rights. Information 168 on the procedures with respect to rights in RFC documents can be 169 found in BCP 78 and BCP 79. 171 Copies of IPR disclosures made to the IETF Secretariat and any 172 assurances of licenses to be made available, or the result of an 173 attempt made to obtain a general license or permission for the use of 174 such proprietary rights by implementers or users of this 175 specification can be obtained from the IETF on-line IPR repository at 176 http://www.ietf.org/ipr. 178 The IETF invites any interested party to bring to its attention any 179 copyrights, patents or patent applications, or other proprietary 180 rights that may cover technology that may be required to implement 181 this standard. Please address the information to the IETF at 182 ietf-ipr@ietf.org. 184 Acknowledgment 186 Funding for the RFC Editor function is provided by the IETF 187 Administrative Support Activity (IASA).