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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 30 Nov 2021 19:45:00 -0800

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 = ?

** 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”.

** 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/

-- 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”.

-- 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?

** 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.

** Section 5.1.1.  Would “_”, “-“, “__--" be considered valid
EntityDomainTypes?  If so, is that desirable?  (it's perfectly reasonable to
say "absolutely")

** 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.

** Section 5.2.1.
-- What’s the thinking on EntityPropertyType having a colon, but
EntityDomainType (Section 5.1.1) cannot?

-- Could “:” or “_::-“ be a valid EntityPropertyType?  If so, is that
desirable?  (it's perfectly reasonable to say "absolutely")

===[ 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/

** Section 3.3.  Editorial.  s/Likewise, a same/Likewise, the same/

** 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.
** Section 8.6.  Typo. s/contanaing/containing/

** Section 9.3.  Typo. s/is is/is/

** Section 9.3.  Typo. s/hierachical/hierarchical/