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 protected]> >Sent: Wednesday, December 1, 2021 4:45 AM >To: The IESG <[email protected]> >Cc: [email protected]; [email protected]; >[email protected]; Vijay Gurbani <[email protected]>; >[email protected] >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 > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
