[Teas] A question about the type definition of tunnel-tp-id

yuchaode <yuchaode@huawei.com> Fri, 15 July 2022 07:59 UTC

From: yuchaode <yuchaode@huawei.com>
To: TEAS WG <teas@ietf.org>
Thread-Topic: A question about the type definition of tunnel-tp-id
Thread-Index: AdiYHzPpKCV20tjwStieR2MySQH+yQ==
Date: Fri, 15 Jul 2022 07:59:36 +0000
Message-ID: <55a160f7fb0d4ab5bb320ba98db15044@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_55a160f7fb0d4ab5bb320ba98db15044huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/DW7InzJsQ0uhuHzRIWoNNPonE8c>
Subject: [Teas] A question about the type definition of tunnel-tp-id
Precedence: list

Hello friends,

When I had discussion with operators and developers, they both raised a question that why the type of TTP was binary type. Could anyone provide some historical considerations of this type definition?
Though I told them this binary value would be encoded to be a string value by BASE64 when present in json format according to RFC7951, they were still confused how to assign an original binary value because they don't used this binary type traditionally.
Most of the vendors and operators like to use name as identifier before, what about change the tunnel-tp-id's type to an union? One option in the union is binary for compatibility consideration and one option is URI which is generic for vendors and operators.

This is my rough thought, please feel free to give your comments. Thank you!

B.R.
Chaode

[Teas] A question about the type definition of tu… yuchaode