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/ _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
