Hi Sabine, all, I would go personally for option 1. Thanks.
Cheers, Med De : Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]> Envoyé : lundi 9 mai 2022 18:20 À : IETF ALTO <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]>; Qin (Bill) Wu <[email protected]>; [email protected]; [email protected] Cc : [email protected]; Jensen Zhang <[email protected]>; Kai Gao <[email protected]>; 'Richard Yang' <[email protected]> Objet : Question on ANE name format Dear ALTO WG and chairs and area directors, The document draft-ietf-alto-unified-props-new-24 (https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-24.txt ) has now entered AUTH48 and is on its way to be published as RFC 9240, once it has been reviewed and approved by all coauthors. In draft-ietf-alto-unified-props-new-24 - Section 10.9. Filtered Property Map for ANEs Example #5, there is an issue, regarding the ANEs name format, on which we would like to have your thoughts and WG chair and area director guidance. Two example ANEs are provided in Section 10.9.: ".ane:dc45.srv9" and ".ane:dc6.srv-cluster8". That is, their ANE names are respectively: "dc45.srv9" and "dc6.srv-cluster8" and both include the '.' separator (U+002E). - The ANE name format is specified in draft-ietf-alto-path-vector-25: https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-25.txt Section 6.1 ANE name. "An ANE Name is encoded as a JSON string with the same format as that of the type PIDName (Section 10.1 of [RFC7285]) " - In Section 10.1 of [RFC7285] https://datatracker.ietf.org/doc/html/rfc7285 "A PID Name is encoded as a JSON string. The string MUST be no more than 64 characters, and it MUST NOT contain characters other than US- ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), the at sign ('@', code point U+0040), the low line ('_', U+005F), or the '.' separator (U+002E). The '.' separator is reserved for future use and MUST NOT be used unless specifically indicated in this document, or an extension document." Since Section 6.1 ANE name of draft-ietf-alto-path-vector-25 does not explicitly allow the '.' separator (U+002E), the example ANE names provided in Section 10.9.of draft-ietf-alto-unified-props-new-24 are illegal. To solve this issue, three options have been identified: ---------- OPTION 1: correct the examples in Section 10.9. of draft-ietf-alto-unified-props-new-24, with for instance: OLD ".ane:dc45.srv9" and ".ane:dc6.srv-cluster8" NEW ".ane:dc45_srv9" and ".ane:dc6_srv-cluster8" OR ".ane:dc45-srv9" and ".ane:dc6-srvcluster8" ---------- OPTION 2: relax the ANE name format in Section 6.1 ANE name of draft-ietf-alto-path-vector-25. Given that PV is as well in the RFC Ed Queue, this may be too late or too complicated at this stage. After all, an ANE name and a PID name are to be interpreted as a string. On the other hand, upon discussions with the PV co-authors, there is no particular reason to forbid '.'. The text of section 6.1 of draft-ietf-alto-path-vector-25 may be updated as follows: OLD An ANE Name is encoded as a JSON string with the same format as that of the type PIDName (Section 10.1 of [RFC7285]). The type ANEName is used in this document to indicate a string of this format. NEW An ANE Name is encoded as a JSON string with the same format as that of the type PIDName (Section 10.1 of [RFC7285]). The type ANEName is used in this document to indicate a string of this format. This document allows to use the '.' separator (U+002E). ---------- OPTION 3: correct the examples in Section 10.9. of UP with for instance + propose extensions on ANE name format in future use cases. What do you recommend? Thanks a lot in advance Sabine and co-authors _________________________________________________________________________________________________________________________ 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.
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
