Re: [alto] Question on ANE name format

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Apologies, re-sending with Wendy and Richard in CC
Sabine

From: alto <[e-mail]> On Behalf Of Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Monday, May 9, 2022 6:20 PM
To: IETF ALTO <[e-mail]>; [e-mail]; Qin (Bill) Wu <[e-mail]>; [e-mail]; [e-mail]
Cc: Kai Gao <[e-mail]>; Jensen Zhang <[e-mail]>
Subject: [alto] 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