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

bruno.decraene@orange.com Wed, 25 March 2020 16:32 UTC

Return-Path: <bruno.decraene@orange.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 F39373A0BF4; Wed, 25 Mar 2020 09:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 DpWhXcy8CiCy; Wed, 25 Mar 2020 09:32:08 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B40E3A0C1A; Wed, 25 Mar 2020 09:32:02 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 48nYYF3cfHz647v; Wed, 25 Mar 2020 17:32:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585153921; bh=koDmYYR5YqJTcSwfNrWLYh5aoDo2FDN353WMMpqfFgg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=m93lyZ9Tu3guZWJadfLQR27vWvP4Uoqw0OV5PMTREBnZMk2R76Mu8T0zbbgMgnVDC bYGDEjTHtWk6xVGnIT0u8NamiGMwgYyl3Vr861DfhSDlOIkWFInX21XlrHrMzseHzZ gKw+MtYFpNHXQfGehvesrCrtyXWf5SOAa7ZQ8M6zuAp5nuOkCk0v1giaCeoVWN/OJ2 cx0AWL4WhDPHYe9yc/FWhHcgXdI1mYL8MFEJ/kSDyoHHLQNU9lFWO9ZaeGZZArQysf EozoPe9Ap1hKmHv3IuAWJHavgVXKlz7ZLI7Ob0fVSw/AJFl/GuaJ4DdYVyUbErK0N0 HaN91gV/W3nhQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 48nYYF3MfkzDq7Q; Wed, 25 Mar 2020 17:32:01 +0100 (CET)
From: <bruno.decraene@orange.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
CC: Jeffrey Haas <jhaas@pfrc.org>, "draft-ietf-idr-segment-routing-te-policy@ietf.org" <draft-ietf-idr-segment-routing-te-policy@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations
Thread-Index: AQHV4fnX9GqjNaH+OECMSUudeTzukagZZg2AgEBZ65A=
Date: Wed, 25 Mar 2020 16:32:01 +0000
Message-ID: <1350_1585153921_5E7B8781_1350_303_1_53C29892C857584299CBF5D05346208A48DFD597@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <20200212231711.GB32507@pfrc.org> <CY4PR11MB158938E9C613B793782A27E1C11A0@CY4PR11MB1589.namprd11.prod.outlook.com>
In-Reply-To: <CY4PR11MB158938E9C613B793782A27E1C11A0@CY4PR11MB1589.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/H1-_bSdCUR6eEWHE4SvB_VhVjd8>
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: Wed, 25 Mar 2020 16:32:13 -0000

Hi Ketan,
 
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
> 
> 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. 

FYI, I've just noticed the following

"All user-visible text fields must be internationalizable. See [RFC 2277] (Alvestrand, H., "IETF Policy on Character Sets and Languages," January 1998.). 
For most cases, this means UTF-8 [RFC 3629] (Yergeau, F., "UTF-8, a transformation format of ISO 10646," November 2003.)."
https://www.ietf.org/standards/ids/checklist/

> The similar object in PCEP is encoded in ASCII - https://tools.ietf.org/html/rfc8231#section-7.3.2

Ah... 

Good luck!
 
--Bruno

 
> Thanks,
> Ketan
> 
> -----Original Message-----
> From: Jeffrey Haas <jhaas@pfrc.org> 
> Sent: 12 February 2020 15:17
> To: draft-ietf-idr-segment-routing-te-policy@ietf.org; 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
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.