RFC 5133

RFC 5133: Terminal Endpoint Identifier (TEI) Query Request Number Change 💖

Okay bestie, let's start with the paperwork 📋✨ This is RFC 5133, written by Michael Tuexen (Muenster Univ. of Applied Sciences) and Ken Morneault (Cisco Systems, Inc.). It's a Standards Track document dated December 2007. It updates RFC 4233 and the header doesn't list anything it obsoletes 🌸

Status of This Memo 🎀

Okay so this document is an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and send ideas for making it better 🫶 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the best part: distribution of this memo is unlimited 🦋

Abstract ✨

So the ISDN Q.921-User Adaptation Layer (IUA) Protocol, which lives in RFC 4233, says the TEI Query Request messages are message type 5 💅 But uh-oh, that number is already taken by the DPNSS/DASS 2 Extensions (DUA) to the IUA Protocol from RFC 4129 😭 That's a whole clash, and this document fixes it by updating RFC 4233 so TEI Query Request messages become message type 8 🔥

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Conventions Used in This Document . . . . . . . . . . . . . . . 2
3.  New Message Type of the TEI Query Message . . . . . . . . . . . 2
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 2
5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 2
6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 2
7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 3

1. Introduction ✨

Okay, the backstory 🕰️ The IUA protocol in [RFC3057] doesn't define a Terminal Endpoint Identifier (TEI) Query Request message at all. Then the DPNSS/DASS 2 Extensions (DUA) to the IUA Protocol in [RFC4129] came along and introduced Data Link Connection (DLC) Status messages of types 5, 6, and 7. After that, [RFC4233] was published, which updates [RFC3057]. [RFC4233] also brought in the TEI Query Request message and gave it type 5 too 🙈 So now you literally can't tell a DLC Status request apart from a TEI Query Request. Chaos, periodt 💀

This document updates [RFC4233] 🎀

2. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the official vibe-check words, so don't mess with them 💜

3. New Message Type of the TEI Query Message 🦋

Here's the fix 🔥 This document updates [RFC4233] by introducing the following change:

Terminal Endpoint Identifier (TEI) Query messages MUST be encoded with a message type of 8 instead of 5 as described in [RFC4233].

Yes, that's the one big rule: TEI Query messages go from 5 to 8 👑

4. IANA Considerations 🌈

In the "Message Types" section of the "Signaling User Adaptation Layer Assignments" registry, IANA has reserved message type 8 of Management Messages for Terminal Endpoint Identifier (TEI) Query Request messages. So IANA put a little reservation sticker on it 🍓

5. Security Considerations 💀

Okay, serious moment 🙈 This document does not require any security considerations in addition to the ones given in [RFC4233]. So the security story is exactly the same as RFC 4233's, nothing extra, nothing sneaky. Go read that one for the full picture 🔒

6. Acknowledgments 🫶

The authors wanted to thank Jon Peterson and Christian Vogt for their invaluable comments. Iconic support, honestly ⭐

7. Normative References 📚

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3057]  Morneault, K., Rengasami, S., Kalla, M., and G.
           Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057,
           February 2001.

[RFC4129]  Mukundan, R., Morneault, K., and N. Mangalpally, "Digital
           Private Network Signaling System (DPNSS)/Digital Access
           Signaling System 2 (DASS 2) Extensions to the IUA
           Protocol", RFC 4129, September 2005.

[RFC4233]  Morneault, K., Rengasami, S., Kalla, M., and G.
           Sidebottom, "Integrated Services Digital Network (ISDN)
           Q.921-User Adaptation Layer", RFC 4233, January 2006.

Authors' Addresses 📮

Michael Tuexen
Muenster Univ. of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany

EMail: tuexen@fh-muenster.de


Ken Morneault
Cisco Systems, Inc.
13615 Dulles Technology Drive
Herndon, VA  20171
US

Phone: +1-703-484-3323
EMail: kmorneau@cisco.com

---

Full Copyright Statement ⚖️

Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 💅

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, THE IETF TRUST 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.

Intellectual Property 🔐

The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, or on whether any license under those rights is available. It also doesn't claim to have searched for any such rights itself. For the procedures around rights in RFC documents, see BCP 78 and BCP 79 📜

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users to use such proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone who's interested to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that information to the IETF at ietf-ipr@ietf.org 🌸