Subject: Re: [alto] Roman Danyliw's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Mon, 28 Feb 2022 15:16:35 +0000

Hello Roman,

Thanks a lot for your review and guidance. Please our proposed updates inline.
We hope they meet your expectations. 
Best regards,
Sabine

>-----Original Message-----
>From: Roman Danyliw via Datatracker <[email-masked]>
>Sent: Wednesday, December 1, 2021 4:45 AM
>To: The IESG <[email-masked]>
>Cc: [email-masked]; [email-masked];
>[email-masked]; Vijay Gurbani <[email-masked]>;
>[email-masked]
>Subject: Roman Danyliw's No Objection on draft-ietf-alto-unified-props-new-
>21: (with COMMENT)
>
>Roman Danyliw has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: No Objection
>
>When responding, please keep the subject line intact and reply to all email
>addresses included in the To and CC lines. (Feel free to cut this introductory
>paragraph, however.)
>
>
>Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>Thank you to Paul Wouters for the SECDIR review.
>
>** Section 3.1.  This section provides a list of examples of entities, but doesn’t
>cite a few of them.  For example: -- as = should be [I-D.ietf-alto-cdni-request-
>routing-alto] -- country = should be [I-D.ietf-alto-cdni-request-routing-alto] --
>network flow = ? -- routing element = ?
>
[ [SR] ] We now refer to [I-D.ietf-alto-cdni-request-routing-alto]  for AS and COUNTRYCODE domains. 
After the list we propose to add the following text
NEW
Some of the example entities listed above are already documented as ALTO entities. The other examples are provided for illustration as potential entities.

>** Section 3.2.1
>   An entity domain type
>   MUST be registered at the IANA, as specified in section
>   Section 12.2.2 and similarly to an ALTO address type.
>
>Per the text in Section 12.2.2, it doesn’t appear that a binding to an ALTO
>address type is required.  For example neither pid or priv have an “ALTO
>address type”.
>
[ [SR] ] Indeed, no binding to ALTO address type is mandatory for an ALTO entity domain type. 
As the text "and similarly to an ALTO address type" seems to introduce confusion and is not really useful at this stage, we have dropped it.

>** Section 4.6
>   Besides, it is also necessary to inform a Client about which
>   associations of specific resources and entity domain types are
>   allowed, because it is not possible to prevent a Server from exposing
>   inappropriate associations.  An informed Client will just ignore
>   inappropriate associations exposed by a Server and avoid error-prone
>   transactions with the Server.
>
>-- Editorial, s/Besides, it is also/It is also/
>
[ [SR] ] as per other review comments, we rephrased the paragraph as follows
OLD
   Besides, it is also necessary to inform a Client about which
   associations of specific resources and entity domain types are
   allowed, because it is not possible to prevent a Server from exposing
   inappropriate associations.  ... 
NEW
   Besides, it is not possible to prevent a Server from mistakenly
   exposing inappropriate associations of information resources and
   entity domain types.  To prevent failures due to invalid queries, it
   is necessary to inform the Client about which associations are
   allowed.  ...

>-- What does it mean that it’s “necessary to inform a Client about which
>associations”?  I was under the impression that this section was documenting
>the IRD capability behavior which is triggered by the client.  If so, the client “is
>asking” in this interaction model rather than being “informed”.
>
[ [SR] ] This section means to help the Client to retrieve entities on which to query properties and also to prevent query failures, by detecting beforehand when an association exposed in the IRD is not valid and will therefore not yield any value. See also the response below.  

>-- What is meant by “it is not possible to prevent a Server from exposing
>inappropriate associations”?  Is it envisioned that the Server might respond
>with an associations which isn’t self-consistent with another part of the
>property map?
>
[ [SR] ] It is envisioned that the Server might my mistake expose an invalid association and that cannot be prevented. Please see our abovementioned update on section 4.6

>** Section 4.6
>For example, the association "costmap3.pid" is not allowed for the
>   following reason: although a cost map exposes PID identifiers, it
>   does not define the set of addresses included in this PID.
>
>I don’t follow what this example is trying to demonstrate – in that, how is it
>related to the what’s supported in the IRD capability.  From the explanation, it
>appears that a costmap and a pid can never be mixed.  No query to an IRD
>would be needed to know that.
>
[ [SR] ] This section actually addresses the potential presence of erroneous associations in the Server and indicates to the Client how to behave then.

>** Section 5.1.1.  Would “_”, “-“, “__--" be considered valid
>EntityDomainTypes?  If so, is that desirable?  (it's perfectly reasonable to say
>"absolutely")
>
[ [SR] ] Yes it is valid, although more "intelligible" names would be desirable.
To express this, we added a paragraph
NEW
Although “_”, “-“, “__--" are valid entity domain types, it is desirable to add characters such as alphanumeric ones, for better intelligibility.

>** Section 5.1.1
>
>   For an endpoint domain type identifier with the "priv:" prefix, an
>   additional string (e.g., company identifier or random string) MUST
>   follow (i.e., "priv:" only is not a valid entity domain type
>   identifier) to reduce potential collisions.
>
>I found this language confusing.  “priv:” is not a domain type identifier.
>It’s only a prefix to the domain type identifier.  It couldn’t be a domain type
>identifier because the colon is not permitted in things of type
>EntityDomainType.  Is this text effectively saying that EntityDomainType has to
>be a non-zero length string, which should be true whether “priv:” is used or
>not.  If so, I’d recommend being clearer.
>
[ [SR] ] UPDATE of Section 5.1.1 (we don't reproduce OLD TEXT for brevity)
----------
Section 5.1.1.  Entity Domain Type

   An entity domain has a type, which is uniquely identified by a string
   that MUST be no more than 64 characters, and 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), or the low line ('_', U+005F).

   The usage of colon (':', U+003A) MUST obey the rules below:

   *  The colon (':', U+003A) character MUST NOT appear more than once,

   *  The colon character MUST NOT be used unless within the string
      "priv:",

   *  The string "priv:" MUST NOT be used unless it starts the string
      that identifies an entity domain type,

   *  For an entity domain type identifier with the "priv:" prefix , an
      additional string (e.g., company identifier or random string) MUST
      follow "priv:", to reduce potential collisions.

   For example, the strings "ipv4", "ipv6", "pid" and "priv:example-
   test-edt", are valid entity domain types. "ipv4.anycast", "pid.local"
   and "priv:" are invalid.

   Although "_", "-", "__--" are valid entity domain types, it is
   desirable to add characters such as alphanumeric ones, for better
   intelligibility.

   The type EntityDomainType is used in this document to denote a JSON
   string meeting the preceding requirements.

   An entity domain type defines the semantics of a type of entity,
   independently of any specifying resource.  All entity domain types
   that are not prefixed with "priv:" MUST be registered with the IANA,
   in the "ALTO Entity Domain Type Registry", defined in Section 12.3,
   following the procedure specified in Section 12.3.2 of this document.
   The format of the entity identifiers (see Section 5.1.3) in that
   entity domain type, as well as any hierarchical or inheritance rules
   (see Section 5.1.4) for those entities, MUST be specified in the IANA
   registration.

   Entity domain type identifiers prefixed with "priv:" are reserved for
   Private Use (see [RFC8126]) without a need to register with IANA.
   The definition of a private use entity domain type MUST apply the
   same way in all property maps of an IRD where it is present.

---------- 
Section 5.1.2 Entity Domain Name
OLD 
   EntityDomainName ::= [[ResourceID] '.' ][priv:]EntityDomainType

   The presence and construction of component

                   "[ [ ResourceID ] '.' ]"

   depends on the category of entity domain.

   The component

                   "[priv:]"

   is present when the entity domain type is defined for Private Use.

NEW
   EntityDomainName ::= [[ResourceID] '.' ]EntityDomainType

   The presence and construction of the component

                   "[ [ ResourceID ] '.' ]"

   depends on the category of entity domain.

>** Section 5.2.1.
>-- What’s the thinking on EntityPropertyType having a colon, but
>EntityDomainType (Section 5.1.1) cannot?
>
[ [SR] ] This inherited from RFC7285 and allows using properties defined for "ipv4" and "ipv6" endpoints" on "ipv4" and "ipv6" entities. 
We have added the following paragragh after parag. 1
NEW
While,  in Section 5.1.1, character ":" is allowed with restrictions on entity domain identifiers, it can be used without restrictions on entity property type identifiers. This relates to RFC7285, where a Server can define properties on endpoints "ipv4" and "ipv6". In the present extension, there is a mapping of ALTO entity domain types "ipv4" and "ipv6", to ALTO address types "ipv4" and "ipv6". Properties defined on "ipv4" and "ipv6" endpoints should be re-usable on "ipv4" and "ipv6" entities. Forbidding the usage of ":" in a non-private entity property type identifier would not allow to use  properties previously defined on "ipv4" and "ipv6" endpoints because their identifiers would be invalid.  

>-- Could “:” or “_::-“ be a valid EntityPropertyType?  If so, is that desirable?
>(it's perfectly reasonable to say "absolutely")
>
[ [SR] ] Similarly to our answer in 5.1.1, we propose to add the following sentence after parag. 1 
NEW
Although “:” or “_::-“ are valid entity domain types, it is desirable to add characters such as alphanumeric ones, for better intelligibility. 

Additionally, in 5.2.2.  Entity Property Name we udated the format as follows
OLD
EntityPropertyName ::= [ResourceID]'.'[priv:]EntityPropertyType
NEW
EntityPropertyName ::= [[ResourceID]'.']EntityPropertyType

>===[ Nits
>
>** Section 1.  Editorial
>   At first, a map of endpoint properties might seem impractical,
>   because it could require enumerating the property value for every
>   possible endpoint.  However, in practice, the number of endpoint
>   addresses involved by an ALTO server can be quite large.
>
>The “However, in practice ” part doesn’t follow from the previous sentence.
>s/However, in practice, the number/The number/
>
[ [SR] ] OK, done, thanks

>** Section 3.3.  Editorial.  s/Likewise, a same/Likewise, the same/
>
[ [SR] ] OK, done, thanks

>** Section 5.1.3.  Editorial.
>
>OLD
>   The format of the second part of an entity identifier depends on the
>   entity domain type, and MUST be specified when defining a new entity
>   domain type and registering it with the IANA.
>
>NEW
>
>   The format of the second part of an entity identifier,
>   DomainTypeSpecificEntityID, depends on the entity domain type, and MUST
>be
>   specified when defining a new entity domain type and registering it with the
>   IANA.
[ [SR] ] OK, done, thanks

>** Section 8.6.  Typo. s/contanaing/containing/
>
[ [SR] ] OK, done, thanks

>** Section 9.3.  Typo. s/is is/is/
>
[ [SR] ] OK, Thanks, we updated as follows
OLD
as is is the case in RFC7285
NEW
as  initially defined in [RFC7285]

>** Section 9.3.  Typo. s/hierachical/hierarchical/
>
[ [SR] ] OK, done, thanks