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

[Vijay Gurbani <[e-mail]>]

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.

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

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

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

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

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

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

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

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

*Nits*:
- S1: s/which is also not globally/that may not be globally/

- S3.2.2: s/A PID is defined relatively to a network map./A PID is defined
relative to a network map./

- S3.4: s/thus conveying values of all property values/thus conveying all
  property values/

- S4.3: s/So that if/Thus, if/

- S4.5: s/ALTO Server may just not provide a/ALTO Server may choose not to
provide a/

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