Dear all,

Please, find here below the review for the Unified Properties draft.

/* General comments */
.- Section 2 – Requirements language – as general comment, the usage of words such as MUST, MAY, etc should be reviewed in all of the occurrences in the text. In some of them they do not appear in capital letters, so not clear if this statements apply or not. Examples of this are: “must” in 2nd paragraph of section 3.2; “must” in 2nd paragraph of section 4.1; “may” in 1st paragraph of section 4.3; etc.
==> DONE: we use keywords in capitals only in normative sections that start in section 5 as per previous reviews. 
====> IN V14: This concern has been addressed as follows:
--- Section  2 has been augmented with the following text,  (as was done in RFC 8896) 
"... when, and only when, they appear in all capitals, as shown here. </t>
    <t>When the words appear in lower case, they are to be interpreted with 
    their natural language meanings.</t>"
---- usage of words in lower case such as "must" and "may" have been double-checked, hoping none have been missed.  

.- References to the need of registering some items at IANA – it is not clear to me if this can be left as it is or if some values have to be proposed in the draft, or at least marked in the text with the idea of substituting such marks by values once IANA register the items. If that is the case, it would be advisable to include (maybe as an annex) a summary table compiling all the items that are expected to be registered. Would it not be part of section 12?
==> YES it is. the document does introduce "pid" entity in the specification text and in the IANA section. Seems it is not highlighted enough we need to see how to do this

.- Along the text it is frequent to find references to other sections before or afterwards. Acknowledging that this could be necessary, it would help the reader to have some summary table (or any other way, like a figure) where the different aspects could be listed beforehand, in such a way that the reader can use it as a kind of map for navigating through the document. I understand it is not easy, so take it as a suggestion for making the document more readable. For instance, some way of showing the relationship among terms in the Terminology section.
==> OK, we will propose a couple of tables to the list to determine which one is the clearest

.- Section 3 presents the basic features of the unified properties while the advanced ones are in section 4. How these extensions co-exist? Are they incremental? What is the reason from presenting them in separate sections? Is it possible to have the basic ones without the advanced features?
==> YES it is 
====> in V14: the paragraph below was added in section 3
<t>The features introduced in this section can be used as standalone. 
  However, in some cases, these features may depend on particular information 
  resources and need to be defined with respect to them.
  To this end, <xref target="anchor"/> introduces addititinal features that extend the ones 
  presented in the present section.</t>

.- Both Section 10 and Appendix A present examples. Would not make sense to move all he examples either to one place or the other?
====> IN V14: Appendix A is originated from our internal discussion about the design principles and is not a specification element. It has been removed from the document

/* Particular comments */
.- Section 1 - Introduction, page 4, 2nd paragraph – “… recent ALTO use cases show …” -> it would be good to be more explicit by listing the use cases that are being referred to.
==> DONE 
.- Section 1 – Introduction, page 5, 1st bullet – fix reference for [REF path-vector]
==> DONE

.- Section 1 – Introduction, page 5, 3rd bullet – “… POST-mode… that returns …” -> would not be “sets” instead of “returns”? 
Agree DONE 

.- Section 1 – Introduction, page 5, 1st paragraph – “extensible” -> “augmentable” ??
DONE
.- Section 1.1 – Terminology – fix the text marked as TBC
DONE

.- Section 2 – Requirements language, 1st paragraph – fix the text marked as TODO.
DONE 

.- Section 3, 1st paragraph – The reference to the assumption of familiarity with ALTO protocol is redundant with the last sentence of section 1 (just before section 1.1 title)
REMOVED from intro

.- Section 3, 1st paragraph – “… ALTO Entities, entities for short” -> “… ALTO Entities, or entities for short”
DONE

.- Section 3.2.2, 1st paragraph – the sentence “An entity domain name …” is hard to understand. Please, revisit and simplify (maybe shortening or dividing it).
DONE: gave a try to simplify the text

.- Section 3.3, 1st paragraph – “Simularly” -> “Similarly”
DONE

.- Section 3.3, bullets in page 9 – is there any inventory of registered types? Are only those provided here as examples?
DONE

.- Section 4.2, penultimate paragraph – “Example resource specific…” -> “Example of resource specific…”
DONE

.- Section 4.4, 2nd paragraph – it would be interesting to perform queries and marking properties that could exclude or filter the entities. For instance to get a list of entities compliant with some property but excluding those that are compliant with another one.
DONE we will consider

.- Section 4.4.3, 1st paragraph – “… inherits no more than one property …” <- why not more than one?
DONE:  for the sake of consistency, an entity must not have more than one value for a property. 
rephrased as follows: “… inherits no more than one property value, for the sake of consistency”, or should we use the phrasing above for more clarity? 

.- Section 4.4.3, 1st paragraph, last sentence – how is it applied? It would be interesting to add some example.
DONE: added in last paragraph "An example illustrating the need for such rules is provided in Section 6.1.3."

.- Section 4.5, 1st paragraph – “Therefore an ALTO server … specifies the properties ...” <- how this advertisement is made?
RE-PHRASED

.- Section 4.5, 2nd paragraph – expand IRD as first occurrence in the text.
DONE

.- Section 4.5, 2nd bullet – “… a list of the names …” <- names or types?
DONE:  it is "names" 

.- Section 4.6, 1st paragraph – “To this end, he …” -> “To this end, the …”
DONE

.- Section 4.6, 1st paragraph – “The syntax of the entity domain identifier … allows the client to infer …” -> would it not be better to follow some rule instead of inferring if it is resource specific or not?
DONE: it is actually difficult to set a rule. As shown in the examples listed below, an entity domain of type "ipv4" may be resource specific (e.g. netmap1.ipv4) or not (e.g. "ipv4"). Should this text be added to clarify? 

.- Section 4.6, last paragraph – is it necessary to have always a Defining Information Resource for each entity domain?
DONE: it is not. Actually section 4.6.1 in its 1st parahraph says: "This concept applies to resource specific domains"
====> IN V14: hopefully helping to address your question
- sentence "that lists all the PIDs used in a cost map" was replaced by "where all the PIDs used in a cost map are defined".
- sentence "Defining Information Resource for the entity domain "pid" " was replaced by "Defining
   Information Resource for the entity domain ++of type++ "pid" "

.- Section 4.6.1, page 16, paragraph “A fundamental attribute …”– I don’t understand the paragraph
====> IN V14: text this paragraph was replaced as follows
OLD
There is a unique association of an entity domain type
   with the media type of its defining information resources.  If an
   entity domain type allows defining information resources, their media
   type is specified in the document that defines this entity domain
   type and in the document that requests the registration of this
   domain type at the IANA.
NEW
There is a unique association between an entity domain
   type and the media type of its defining information resource.  When
   an entity domain type allows associations with defining information
   resources, the document that defines this entity domain type
   specifies the media type of the potential defining information
   resource.  Likewise, the IANA registration of an entity domain type
   also specifies the media type of potential defining information
   resources.

.- Section 4.7, 1st paragraph -- “The PID value for an IPv4 …”– I would suggest to rephrase, hard to understand.
====> IN V14 sentence was changed as follows: 
OLD
The PID value for an IPv4 address differ in different network maps or not be defined for some of them
NEW
The PID value returned for an IPv4 address is specific to the network map defining the PID and may differ from one network map to another one. 

.- Section 4.7, 2nd paragraph – “… needs to be aware of aware of appropriate …” -> “… needs to be aware of appropriate …”
==> DONE

.- Section 5, title – “… Basic Data Type …” -> here it is mentioned “type” but later on it is described “name”; is this type the same type of 5.1.1?
====> IN V14: Section 5.1.2 starts with the following added sentence:  "As said in Section 3.2 when introducing entity domains, an entity domain is characterized by its type and identified by its name."

.- Section 5.1.1, 1st paragraph – “The ?.? separator …” -> should not be written as “The “?.?” Separator”. Also in section 5.2.1.
==> DONE
====> IN V14: to harmonize within and with RFC 7285  expressions such as: ?.? or "." are turned into '.' throughout the document, hoping all of them were caught

.- Section 5.1.2, last sentence – “… in an information resources ID.” -> “… in an information resource ID.”
====> IN V14 DONE

.- Section 5.1.2.3, 1st paragraph – “… property map would not be relevant for …” -> “… property map not being relevant for …”
====> IN V14, 1st paragraph is modified as follows:
"A property map can define properties on entities that are specific to
   a unique information resource, which is the property map itself.
   This may be the case when an ALTO Server provides properties on a set
   of entities that are defined only in this property map, are not
   relevant to another one and do not depend on another specific
   resource."

.- Section 5.1.2.3 – it would be good to provide an example as in 5.1.2.1 and 5.1.2.2.
====> IN V14 provided the following example
"For example: a specialised property map may define a domain of type
   "ane", defined in [I-D.ietf-alto-path-vector], that contains a set of
   ANEs representing data centers, that each have a persistent
   identifier and are relevant only to this property map."

.- Section 6.1.3, figure 2 – should not be inherited more than one property? For instance, in the case of 192.0.2.0 several properties could apply.
====> IN V14: in paragraph 1, last sentence was changed as follows
OLD
Note that this longest prefix rule ensures no multiple inheritances, and hence no ambiguity.
NEW
Note that this longest prefix rule ensures no multiple ++  value ++ inheritances, and hence no ambiguity.

.- Section 6.3, 1st sentence – “… are completely separate, …” -> “… are completely separated, …”
====> IN V14, as the intented meaning is "disctinct" the text of section 6.3 has been clarified (i) with the 1st sentence as follows and (ii) with the addition of term "type" wherevever applicable. 
"Because the Internet address and PID domains relate to completely
      distinct domain types, the question may arise as to which entity domain type is the
      best for a property."


.- Section 12.3, last paragraph – fix the text marked as TODO.
DONE

Best regards

Luis

__________________________________
Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): +34 91 312 9084
Mobile: +34 680 947 650
luismiguel.contrerasmurillo@telefonica.com