idnits 2.17.1 draft-ietf-sigtran-rfc4233update-00.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 on line 163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 147. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 153. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 26, 2006) is 6511 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 (ref. '2') (Obsoleted by RFC 4233) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 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 Expires: December 28, 2006 K. Morneault 5 Cisco Systems, Inc. 6 June 26, 2006 8 TEI Query Request Number Change 9 draft-ietf-sigtran-rfc4233update-00.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 December 28, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The IUA protocol described in RFC4233 defines the messages type of 43 TEI Query Request messages as 5. But this number is already used by 44 the IUA extension DUA described in RFC4129. This document updates 45 IUA such that the message type of TEI Query Request messages is 8. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. New Message Type of the TEI Query Message . . . . . . . . . . . 3 52 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 54 6. Normative References . . . . . . . . . . . . . . . . . . . . . 3 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 56 Intellectual Property and Copyright Statements . . . . . . . . . . 6 58 1. Introduction 60 The IUA protocol described in RFC3057 [2] does not define a TEI Query 61 Request message. The IUA extension DUA described in RFC4129 [3] 62 introduces DLC Status messages of type 5, 6, and 7. After that 63 RFC4233 [4] was published, which updates RFC3057 [2]. This document 64 also introduces the TEI Query Request message and uses the message 65 type of 5 for it. This makes it impossible to differentiate the DLC 66 Status request from a TEI Query Request. 68 This document updates RFC4233 [4] 70 2. Conventions 72 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 73 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 74 they appear in this document, are to be interpreted as described in 75 RFC2119 [1]. 77 3. New Message Type of the TEI Query Message 79 This document updates RFC4233 [4] by introducing the following 80 change. 82 TEI Query messages MUST be encoded with a message type of 8 instead 83 of 5 as described in RFC4233 [4]. 85 4. IANA Considerations 87 IANA should reserve the message type 8 of Management Messages for TEI 88 Query Request messages. 90 5. Security Considerations 92 This document does not require any security considerations in 93 addition to the one given in RFC4233 [4]. 95 6. Normative References 97 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 98 Levels", BCP 14, RFC 2119, March 1997. 100 [2] Morneault, K., Rengasami, S., Kalla, M., and G. Sidebottom, 101 "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001. 103 [3] Mukundan, R., Morneault, K., and N. Mangalpally, "Digital 104 Private Network Signaling System (DPNSS)/Digital Access 105 Signaling System 2 (DASS 2) Extensions to the IUA Protocol", 106 RFC 4129, September 2005. 108 [4] Morneault, K., Rengasami, S., Kalla, M., and G. Sidebottom, 109 "Integrated Services Digital Network (ISDN) Q.921-User 110 Adaptation Layer", RFC 4233, January 2006. 112 Authors' Addresses 114 Michael Tuexen 115 Muenster Univ. of Applied Sciences 116 Stegerwaldstr. 39 117 48565 Steinfurt 118 Germany 120 Email: tuexen@fh-muenster.de 122 Ken Morneault 123 Cisco Systems, Inc. 124 13615 Dulles Technology Drive 125 Herndon, VA 20171 126 US 128 Phone: +1-703-484-3323 129 Email: kmorneau@cisco.com 131 Intellectual Property Statement 133 The IETF takes no position regarding the validity or scope of any 134 Intellectual Property Rights or other rights that might be claimed to 135 pertain to the implementation or use of the technology described in 136 this document or the extent to which any license under such rights 137 might or might not be available; nor does it represent that it has 138 made any independent effort to identify any such rights. Information 139 on the procedures with respect to rights in RFC documents can be 140 found in BCP 78 and BCP 79. 142 Copies of IPR disclosures made to the IETF Secretariat and any 143 assurances of licenses to be made available, or the result of an 144 attempt made to obtain a general license or permission for the use of 145 such proprietary rights by implementers or users of this 146 specification can be obtained from the IETF on-line IPR repository at 147 http://www.ietf.org/ipr. 149 The IETF invites any interested party to bring to its attention any 150 copyrights, patents or patent applications, or other proprietary 151 rights that may cover technology that may be required to implement 152 this standard. Please address the information to the IETF at 153 ietf-ipr@ietf.org. 155 Disclaimer of Validity 157 This document and the information contained herein are provided on an 158 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 159 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 160 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 161 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 162 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 163 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 165 Copyright Statement 167 Copyright (C) The Internet Society (2006). This document is subject 168 to the rights, licenses and restrictions contained in BCP 78, and 169 except as set forth therein, the authors retain all their rights. 171 Acknowledgment 173 Funding for the RFC Editor function is currently provided by the 174 Internet Society.