Re: [alto] Chair review of unified-props (Part 1 of 2)

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

Hello Vijay,

Thank you for your review of Entity Property Maps. As promised, please find inline the answers from Jensen and myself on how your comments have been addressed, prefixed respectively by “[jensen]” and “(sabine)”.
Responses on sections 4.7.1 and 4.4.3, with “*****” request further feedback from you.
Thanks,
Sabine

From: Vijay Gurbani <[e-mail]>
Sent: Tuesday, January 26, 2021 5:06 PM
To: [e-mail]
Cc: IETF ALTO <[e-mail]>
Subject: Chair review of unified-props (Part 1 of 2)

All: My apologies for the late start on the chair reviews of the documents I am shepherding.  However, I have started the review.

Below is the first (of two parts) review of unified-props.  This review includes all sections from Abstract to Section 4.7.1 (inclusive).

Please let me know if you have any questions.  I will post the second part tomorrow.

Chair review from Abstract - Section 4.7.1 (inclusive).

Major:

- Abstract: "...by generalizing the concept of "endpoint properties" to generic
type of entities..." ==> Note that the antecedent ("endpoint properties") and
the consequent ("type of entities") do not match.  Perhaps better to say: "...by
generalizing the concept of "endpoint properties" as applied to endpoints
defined by IP addresses to endpoints a wider set of objects..."

More concretely:

OLD:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
to generic types of entities, and by presenting those properties as
maps, similar to the network and cost maps in the base ALTO protocol.

NEW:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
as applied to endpoints as defined by IP addresses to endpoints defined
by a wider set of objects.  Further, these properties are presented
as maps, similar to the network and cost maps in the base ALTO protocol.
[ [SR] ] [Jensen] It looks good to me. Done.


- S3.2.1: "An entity domain type is expected to be registered at the IANA" ==>
you mean "MUST be registered with IANA"?  Or "SHOULD be registered with IANA"?
Best to use normative language here, unless you have a specific reason not
to.
[ [SR] ] [Jensne] We changed "is expected to" to "MUST". Thanks for pointing it out.
I don't see any reason not to do it.

- S3.2.2: What does this mean: "As a consequence, entities in such
domains may be defined in a resource handling this domain type but
not in other resources handling this same domain type."?  I am unable to
parse this, I think you are saying that of all the resources handling a
particular domain type, the entity must be defined in only one of them.  If
so, perhaps best to reword; something like:
   OLD:
   As a consequence, entities in such domains may be defined in a
   resource handling this domain type but not in other resources handling
   this same domain type.
   NEW:
   As a consequence, of all the resources defining a particular domain
   type, the entity must be defined in only one resource.
[ [SR] ] (Sabine)
the point is rather to say that a domain can contain entities defined relatively to an information resource. In this case, the domain needs to have a name that ensures that the entities of the domain can all be retrieved and that with no ambiguities.
For instance: we may have 2 domains, "netmap1.pid" = {"mypidP", "mypidB", "mypidS"} and  "netmap2.pid" = {"mypidP", "mypidB", "mypidL"} . "mypidP" may or may not point to the same addresses in "netmap1" and "netmap2". This is not problematic as long as, when the Client queries "mypidP" defined in "netmap1" or "netmap2", it gets what is defined in these network maps for "mypidP".
The text has been rephrased in this direction. Please let us know if it is clear enough.

- S4.2.2, first paragraph: Is this example valid?  From my experience, ASN's
contain IPv4 addresses defined by a CIDR block.  I think it is highly unlikely
that a service provider will define a CIDR block (192.0.1.0/24<http://192.0.1.0/24>) and have that
block span ASNs, but perhaps I am mistaken.  Perhaps someone from network
operations may want to look at this example and bless it, or if you are sure
that networks are architected in such a manner, then we can let it stay.
[ [SR] ] (Sabine)
Agree. Property "ASN" has been replaced with dummy property value "P".


- S4.6.2: "When an ANE has a persistent identifier, say, "entity-4", the
latter", here what do you mean by "latter"?  In this sentence, I do not see two
things that can be characterized as "former" and "latter"...?
[ [SR] ] [Jensen] New sentence: "An ANE may have a persistent identifier, say, "entity-4",
that is provided by the Server as a value of the "persistent-entity-id" property of this ANE."
(sabine)
the following sentence was also clarified as follows:
OLD
Further properties may be queried on an ANE with a persistent entity ID.
NEW
Further properties may then be queried on an ANE by using its persistent entity ID

- S4.7.1: This subsection appears as an afterthought; it is not "defining
resource media-types" as much as simply "listing resource media-types".  It does
not appear to be comprehensive since it only includes two examples, which leads
me to think that perhaps these examples are best put in parts of the text that
refer to these property types.  Furthermore, the media type for property "pid"
is already defined in RFC7285, so if you want to give an example here, simply
refer to RFC7285 for it.  And, the media type "alto-cdnifci+json" is defined in
draft-ietf-alto-cdni-request-routing-alto, not in this section.  My advice would
be to remove this subsection, I don't think it is comprehensive and just adds to
the confusion.
[ [SR] ] (Sabine) *****
Actually we removed 4.7.1 and the text of 4.7 (not the title yet).
Most of the text of 4.7 was moved to 4.6.1 last paragraph, as 4.7 “looked” too small.
However, even if the text of 4.7 is short,
it is important, as it introduces fields that must be specified at the IANA, as specified in section 12.3.
So we may just put the text back in 4.7, if you think it is better.

Minor:
- S3.1: in the bullet items, please be consistent when using "IPv4 or IPv6"
versus "ipv4 or ipv6".  Both forms are used, best to choose one and be
consistent in the section.  (I recognize that lower case "ipv4" and "ipv6" are
used elsewhere in the document to define entity domains, that is okay; just be
consistent in S3.1.)
[ [SR] ] [Jensen] Thanks for noticing this issue. Done.

- S3.1, last bullet item: What os a "routable network node"?  Is a network node
that performs the routing function (a router)?  or is it a network node that is
the recipient of a packet routed to it (an endpoint)?
[ [SR] ] [Jensen] It should be the former one. The term "routable network node" may be confusing.
We will just use "router" instead.

- S4.4.3: s/sets in the upper level./subsets./
Rationale: "Upper level" of a set consists of elements that are subsets. Since
you are using set theory here, perhaps best to use nomenclature in that
domain.  (You may edit it as "subsets (upper levels)." if that helps.

- S4.4.3: Similarly, "lower level" is "superset".
[ [SR] ] (sabine)  *****
the text has been updated and uses  "subsets" (upper level) and "superset" (lower level).
However we are not sure this reflects the rationale for property inheritance in a hierarchical entity set.
What we mean is that a set S1 at a given "upper" level of the hierarchy covers more values than a set S2 defined at a "lower" level of the hierarchy.  Therefore, S2 at "lower" level is a subset of S1 at "upper" level.
Therefore, we would rather use: supersets (upper levels), subsets (lower levels)
For instance: What we mean is that a set S1 defined by address bloc 1.2.3.4/24 which is defined at a given "upper" level of the hierarchy contains more address values than a set S2 defined by address bloc 1.2.3.4/30, defined at a "lower" level of the hierarchy.  Therefore, S2 at "lower" level is a subset of S1 at "upper" level.


Nits:
- S1: s/which is also not globally/that may not be globally/
[ [SR] ] [Jensen] Done.


- S3.2.2: s/A PID is defined relatively to a network map./A PID is defined
relative to a network map./
[ [SR] ] [Jensen] Done.


- S3.4: s/thus conveying values of all property values/thus conveying all
  property values/
[ [SR] ] [Jensen] Done.


- S4.3: s/So that if/Thus, if/
[ [SR] ] [Jensen] Done.


- S4.5: s/ALTO Server may just not provide a/ALTO Server may choose not to
provide a/
[ [SR] ] [Jensen] Done.


- S4.6: s/define them, that is, the set of addresses included in this
PID./define the set of addresses included in this PID./
[ [SR] ] [Jensen] Done.