Re: [Idr] draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Thu, 30 April 2020 08:09 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005C73A0B0B for <idr@ietfa.amsl.com>; Thu, 30 Apr 2020 01:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HE5qwGT3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hio7USZ3
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZMMRNLr7PTT for <idr@ietfa.amsl.com>; Thu, 30 Apr 2020 01:09:52 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89F93A0B07 for <idr@ietf.org>; Thu, 30 Apr 2020 01:09:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27510; q=dns/txt; s=iport; t=1588234191; x=1589443791; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oIRWF16pxHuJ+bOcYMN+8vS6uv2UNprONAVSaC3YVgQ=; b=HE5qwGT3zTuH1wQUxlENMu7jhuJofNQZD7kVueuGD5ieMhDaWBaKm7f5 khz2EKKrI6eytKjuOi4ZzhcNbqiy8yD1ssmyDM+PvbI1KsLNETOU4UCY0 Ly3+ROLKHHHbLfEvcmpsBPD7L3p/32DixnHpyddY1TBhJE9aS+bagdqQa c=;
IronPort-PHdr: 9a23:KuPbShQVetvTdL0kSxYRFD8RNtpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESQB9mJ5/dNkeGQsq38VyoH+5nS+HwBcZkZURgDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4TsbAB65NAdpKKLyAIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR6cqXpTcOMQzmRtdl8=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B9AAAAh6pe/5ldJa1cChsBAQEBAQEBAQUBAQESAQEBAwMBAQGBdgMBAQELAYEkLyQtBW5YLyoKhBeDRgONQol2jjuBQoEQA1QLAQEBDAEBGAEMCAIEAQGDf0UCF4IYJDcGDgIDAQELAQEFAQEBAgEFBG2FVgyFcQEBAQEDAQEQEQoTAQEsCwELBAIBCBEEAQEoAwICAh8GCxQJCAIEAQ0FCA0NgwWBfk0DLgEOp3cCgTmIYXaBMoMAAQEFhSwNC4IOAwaBOAGCYoJHDocJGoFBP4ERQ4JNPoIeSQEBAgGBLQEHBQYBIwUHCRYJglwzgi2ORCmCUoYVJJlFMkoKgkWHH3SLLIRlgluIW5FRkAWBV4d0gkWQfQIEAgQFAg4BAQWBaCNmcHAVO4JpUBgNimiHUwkaFYM6hRSFQnQCATMCBgEHAQEDCXyPKoE0AYEPAQE
X-IronPort-AV: E=Sophos;i="5.73,334,1583193600"; d="scan'208,217";a="471043727"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2020 08:09:50 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03U89oMB028535 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2020 08:09:50 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Apr 2020 03:09:50 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Apr 2020 04:09:48 -0400
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 30 Apr 2020 03:09:48 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DrMEWXDSy6J3cknLYTHX4UfNFVpPhPKGPdSiD0OmPbVBcEu/D5nvMrnjzaz596aLdyloKZbRcp1gWnpmcbM9uYO/U0or1Xf85wTIGW91NfMJxlfukQ7u+QeunGWt92qG3D4Ff6Ftxr7DvAU8sPJDoxQwQKCmnnDRtuPT796wn3Qvp1BAGgZ2chi/WwW1ZGyXGyOCREC70qwLmZXNp4Zdyuf9dxPdhRabkndRvHOgLsiUbPcVq7hx83OoJBHH6GkEStt6Kad85nawMwdMBif0uw85Fl+WjbhIZnm/s23BRVaO1v24p42ex17v0vaTZUs7/N6rbMBNu5KgxQW/Xov5Vg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oIRWF16pxHuJ+bOcYMN+8vS6uv2UNprONAVSaC3YVgQ=; b=jTiinUXYIdy7I0WIMyYqF4IyqpURN9sbaIxR33gxnjSrAPu9yWicZ5it2H06FaYeevde1SH/p1AO8c2DzWNQeiqlCkb4mJPRhqxluS9Tqm7mkoAwpq/NhC2QZru8kft9ECee2H+JIaH1+sBt5kPevHOuBMwn8yTEynMkJgncwkrw8gMsumg2clyNWBDxAo1kHC3Kkv7pSjhZ59TiT9czhMP+xvXgnPP2yqB0pkLFc0Yspy+a7OoMPhD0pi/lkCYNGwXSazEdK7VT77Qe5kR/9aYf7Jrdr/iNIngiHnP4Qnkx9u1jC3eAYQIaoeKC1f8XVBtH9y46N2Zkx7eYahHUPw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oIRWF16pxHuJ+bOcYMN+8vS6uv2UNprONAVSaC3YVgQ=; b=hio7USZ3g9k2kEmk/MQsVd3gEVdKisV1mtEYPYj0NhEFiplRMUc+nNBQ/uaTgc0CqfRqU2OqHfqbBv406P/i8zvmxD56nj6LhnMdEuNeB4jF+g3i96Ifdlfaz+DDWnvnOam9Rf414xq9+Mg/15oHdScZQ113DhGajGn7x9SIAFg=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4539.namprd11.prod.outlook.com (2603:10b6:303:2f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Thu, 30 Apr 2020 08:09:47 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c%6]) with mapi id 15.20.2958.020; Thu, 30 Apr 2020 08:09:47 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Nandan Saha <nandan=40arista.com@dmarc.ietf.org>, Andrew Alston <Andrew.Alston@liquidtelecom.com>
CC: idr wg <idr@ietf.org>
Thread-Topic: [Idr] draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations
Thread-Index: AQHV4fnX9GqjNaH+OECMSUudeTzukagZZg2AgCujLxCAAAX2AIAANRWAgEyEzfA=
Date: Thu, 30 Apr 2020 08:09:47 +0000
Message-ID: <MW3PR11MB45708350FC84A755EFB8E1CFC1AA0@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <20200212231711.GB32507@pfrc.org> <CY4PR11MB158938E9C613B793782A27E1C11A0@CY4PR11MB1589.namprd11.prod.outlook.com> <MW3PR11MB4570FBEA8FF155159F98D47BC1FD0@MW3PR11MB4570.namprd11.prod.outlook.com> <DBBPR03MB541560C419E5DBED917B8891EEFD0@DBBPR03MB5415.eurprd03.prod.outlook.com> <CAE+itjccvXbCsQSDOrRdK2hBkg-Kp15ca-qQ6-GNWTeRFpEavA@mail.gmail.com>
In-Reply-To: <CAE+itjccvXbCsQSDOrRdK2hBkg-Kp15ca-qQ6-GNWTeRFpEavA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c5e93536-4b49-4d7a-01b2-08d7ecddd96f
x-ms-traffictypediagnostic: MW3PR11MB4539:
x-microsoft-antispam-prvs: <MW3PR11MB4539781189E70C409B61DA05C1AA0@MW3PR11MB4539.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0389EDA07F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VEhBfs6HOlBXDPdsMAfB4h3/BCHOYFCUmxQ0LAJ7GzoLe7luTss/+45rH8JqbUKPLRpADX5mmup3nD45U95XJl1mkb0Lw3eiJWeZDAW35pjS0naxoN+ZHXjSXqVjzBrvP74wYfQdSzm6XXxxymGrf+AE8qkAv7ppLvupI2OPjMele0T7cCuOughu6EgpeXAGCy5g0bJu0UioSv5VFrDxs0Vzv6QOEaqGVrRQ8anrha4k/fVMIiP2Wz6lWXpcsv1FCZTn7pnrSAU61XAaT2VNPRU/dSisBUVa8WaZicUGwFe6Jx0A8UAYbWz4/Rtk+hDof79fwhx/iBzM0a8H//XgXDOppQhHcsnRKvKwRiMQL1itq7XzOW+qcTQ0LdJ6AUusl8ZWh5TzzoJtT64DMYAn0TzWzjT0Rxv8gPWeghbGr/H43cUjblYhqYrbdFF4lXx7vffIHQExwDuIhD+PwmTOU8iFy7w7KkFnU8PwgZBid7PH2ONUu9A5UkQbWNyvNDtczD+32dZYmWWc3ja/niU7zg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(76116006)(71200400001)(66946007)(53546011)(2906002)(33656002)(186003)(64756008)(66446008)(86362001)(66556008)(966005)(66476007)(6506007)(7696005)(52536014)(4326008)(8676002)(55016002)(26005)(478600001)(8936002)(110136005)(316002)(9326002)(5660300002)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: CEtVTDSHoBh08LLVo0WE17wgF6UCwr/SnOhZm/7aYx1oIBHP7jeR4LPT27bY2R3eobpxQsGV1KvnbfQ6l44JJLXqpuBfiz5ybAobYjZkqPBjZKClrloWLH/FMvU5gv3JvnFjlY4VVzvGLyh/sVAzx6T2jv7prV7Zs5wUWiVFuGIqge0foir8wlfgsfGgIal6yeOMQJqEgyajR5XsyH9giMvW8qxZ09TahKIawe+tIIirYXyNYKcz3JAw7oQnE66eARedLcBwsb0Yp5wn/kflembynNjEs4MBiqmiOA/EQwrN38y/78NIsA9njdJvvWW5sRDgSYMgbQxJMBkyp0JoS1szg5htt8GDEugPby1pMnjbUtKco5w/2E9mL76iBFUqIR41SqneiyQYb5JR6/dFb6hub4lKsVna+cd/lhm73wn7RH9qV1lz9BZ4FCnoi6OdEe1JoBasa+pBvmneJCnYp+XLN+5iz1ypgzrWF/XR8cNpLAF3kdvizWxovOuUNrWX203XW7+Ts5X2TVhNxpR0mBA5yFXON6Vr67rJKf+esZ8zhL0ePBOKUB6lqa/JIyzIcj0xfHwvYsHUcdGVH7rv8oRCZfp2/sQOn2JMuE4tJSDN2xgWxcSJNIfCbd3mnTcOV2klAnsuIFSgNg6iCz/HCxFmJQyNl4bEXPLHERlTTxKKVI9BZRE7afykugwDfdLlRVjtjFPfF++BZtsu3wuJPDh8Tey+V64jM43wGfsXhZFlf3Exz3cbOOK0egtJg5ZP9A8hir1hGzBgHJD+gQIZH3qjYa/NhEuAMv08/UL2FME=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45708350FC84A755EFB8E1CFC1AA0MW3PR11MB4570namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c5e93536-4b49-4d7a-01b2-08d7ecddd96f
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 08:09:47.2339 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: klqjmSCi71yc1PEFBKn+4FR3KSRaqANixZ2migT7yfKzX/Bch0GqHDc5cbu9cnjYUtUmOFZYIBJtZw45/8l1Ug==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4539
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IvldjDUkYHJnn0xTU9lqp6k8yfQ>
Subject: Re: [Idr] draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Apr 2020 08:09:55 -0000

Hi Nandan,

Looks like I missed to acknowledge your email. I agree and will change s/Policy Name/Policy Candidate Path Name/ in the next update.

Thanks,
Ketan

From: Nandan Saha <nandan=40arista.com@dmarc.ietf.org>
Sent: 12 March 2020 21:07
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Ketan Talaulikar (ketant) <ketant@cisco.com>; idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations

On a slight tangent, can we please call the sub tlv "Candidate path name" or some such. It's more accurate than "policy name" since the candidate path is signalled in bgp, not a policy..

On Thu, Mar 12, 2020 at 5:57 PM Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>> wrote:
I would be quite happy to stick to ascii here – it makes writing implementations simpler – and while I’ve seen one hardware vendor that had an entire cli in Cyrillic -  I’m not entirely sure that it justifies such a change.

Then again – I’m a native English speaker so I’m biased – and the preference here isn’t really strong on my side.

Andrew


From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, 12 March 2020 15:22
To: idr@ietf.org<mailto:idr@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Cc: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>; draft-ietf-idr-segment-routing-te-policy@ietf.org<mailto:draft-ietf-idr-segment-routing-te-policy@ietf.org>; Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail..com>>
Subject: Re: [spring] draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations

Hello,

Would like to bring back this topic for discussion and inputs from the IDR & SPRING WGs.

We need to ask if the "SR Policy Name" object is something that needs localization (i.e. we change the encoding from ASCII to UTF-8).

According to rfc6365 "Localization is the act of tailoring an application for a different language or script or culture." The question then arises: would someone want to define a policy name in something other than a language supported by ASCII? English is supported, but there are other languages which are not.

This object traces it roots to the draft-ietf-spring-segment-routing-policy document which indicates the use of "printable ASCII characters" : https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-06#section-2.1
So any changes to the encoding would need to be reflected in this document (and other protocols and Yang models as an extension).

Further on, the equivalent object in PCEP has been already defined as using ASCII in the now published https://tools.ietf.org/html/rfc8231#section-7.3.2

Based on the WG inputs, we can determine the next course of action.

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant)
Sent: 13 February 2020 23:38
To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>; draft-ietf-idr-segment-routing-te-policy@ietf.org<mailto:draft-ietf-idr-segment-routing-te-policy@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations

Hi Jeff,

I agree with you about the limits on the policy name size.

I am not aware of any IETF standard that mandates the use of UTF-8 for encoding of string for names. The similar object in PCEP is encoded in ASCII - https://tools.ietf.org/html/rfc8231#section-7.3.2

Thanks,
Ketan

-----Original Message-----
From: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Sent: 12 February 2020 15:17
To: draft-ietf-idr-segment-routing-te-policy@ietf.org<mailto:draft-ietf-idr-segment-routing-te-policy@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Subject: draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations

Authors,

In draft-ietf-idr-segment-routing-te-policy-08, Section 2.4.6 we have a TLV for Policy Name. Its text is:

: 2.4.6. Policy Name Sub-TLV
:
: An operator MAY set the Policy Name sub-TLV to attach a symbolic name
: to the SR Policy candidate path.
:
: Usage of Policy Name sub-TLV is described in section 2 in
: [I-D.ietf-spring-segment-routing-policy].
:
: The Policy Name sub-TLV may exceed 255 bytes length due to long
: policy name. Therefore a 2-octet length is required. According to
: [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV codepoint
: defines the size of the length field. Therefore, for the Policy Name
: sub-TLV a code point of 128 or higher is used.
:
: The Policy Name sub-TLV is optional and it MUST NOT appear more than
: once in the SR Policy TLV.
:
: The Policy Name sub-TLV has following format:
:
: 0 1 2 3
: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: | Type | Length | RESERVED |
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: // Policy Name //
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
: Where:
:
: Type: 129.
:
: Length: Variable.
:
: RESERVED: 1 octet of reserved bits. SHOULD be set to zero on
: transmission and MUST be ignored on receipt.
:
: Policy Name: Symbolic name for the policy. It SHOULD be a string
: of printable ASCII characters, without a NULL terminator.

draft-ietf-spring-segment-routing-policy-06, Section 2.1 discusses this
Sub-TLV:

: An implementation MAY allow assignment of a symbolic name comprising
: of printable ASCII characters to an SR Policy to serve as a user-
: friendly attribute for debug and troubleshooting purposes. Such
: symbolic names may identify an SR Policy when the naming scheme
: ensures uniqueness.

There are two observations I'd like to make:
1. A 65K length isn't very likely in BGP. :-) I suggest that greater guidance for shorter names should be offered. For example, perhaps limit the length to 1K. Alternatively, offer advice such as: "Implementations may choose to truncate long Policy Names".

2. The guidance about "printable ASCII" is rather old-style and likely to run askance of IESG review for internationalization considerations... I'd suggest that the field be encoded in UTF-8 and make reference to print-safety similar to RFC 8203 (BGP Administrative Shutdown) in its Security Considerations.

-- Jeff

_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr