Dear Luis,
Thanks a lot for your review. Your comments have been addressed partly in v13
and v14, except providing a table listing the protocol extensions. I have
attached a text file that lists your review comments and indicates where they
were addressed in v13 and v14.
The description text of updates made specifically in V14 starts with "====> IN
V14".
Please let me know whether the updates meet your expectations.
Best regards,
Sabine
From: alto <[email protected]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Monday, October 12, 2020 10:44 PM
To: '[email protected]' <[email protected]>
Subject: [alto] Review for draft-ietf-alto-unified-props-new-12
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.
.- 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?
.- 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.
.- 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?
.- Both Section 10 and Appendix A present examples. Would not make sense to
move all he examples either to one place or the other?
/* 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.
.- Section 1 - Introduction, page 5, 1st bullet - fix reference for [REF
path-vector]
.- Section 1 - Introduction, page 5, 3rd bullet - "... POST-mode... that
returns ..." -> would not be "sets" instead of "returns"?
.- Section 1 - Introduction, page 5, 1st paragraph - "extensible" ->
"augmentable" ??
.- Section 1.1 - Terminology - fix the text marked as TBC
.- Section 2 - Requirements language, 1st paragraph - fix the text marked as
TODO.
.- 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)
.- Section 3, 1st paragraph - "... ALTO Entities, entities for short" -> "...
ALTO Entities, or entities for short"
.- 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).
.- Section 3.3, 1st paragraph - "Simularly" -> "Similarly"
.- Section 3.3, bullets in page 9 - is there any inventory of registered types?
Are only those provided here as examples?
.- Section 4.2, penultimate paragraph - "Example resource specific..." ->
"Example of resource specific..."
.- 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.
.- Section 4.4.3, 1st paragraph - "... inherits no more than one property ..."
<- why not more than one?
.- Section 4.4.3, 1st paragraph, last sentence - how is it applied? It would be
interesting to add some example.
.- Section 4.5, 1st paragraph - "Therefore an ALTO server ... specifies the
properties ..." <- how this advertisement is made?
.- Section 4.5, 2nd paragraph - expand IRD as first occurrence in the text.
.- Section 4.5, 2nd bullet - "... a list of the names ..." <- names or types?
.- Section 4.6, 1st paragraph - "To this end, he ..." -> "To this end, the ..."
.- 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?
.- Section 4.6, last paragraph - is it necessary to have always a Defining
Information Resource for each entity domain?
.- Section 4.6.1, page 16, paragraph "A fundamental attribute ..."- I don't
understand the paragraph
.- Section 4.7, 1st paragraph -- "The PID value for an IPv4 ..."- I would
suggest to rephrase, hard to understand.
.- Section 4.7, 2nd paragraph - "... needs to be aware of aware of appropriate
..." -> "... needs to be aware of appropriate ..."
.- 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?
.- Section 5.1.1, 1st paragraph - "The ?.? separator ..." -> should not be
written as "The "?.?" Separator". Also in section 5.2.1.
.- Section 5.1.2, last sentence - "... in an information resources ID." -> "...
in an information resource ID."
.- Section 5.1.2.3, 1st paragraph - "... property map would not be relevant for
..." -> "... property map not being relevant for ..."
.- Section 5.1.2.3 - it would be good to provide an example as in 5.1.2.1 and
5.1.2.2.
.- 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.
.- Section 6.3, 1st sentence - "... are completely separate, ..." -> "... are
completely separated, ..."
.- Section 12.3, last paragraph - fix the text marked as TODO.
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
[email protected]<mailto:[email protected]>
________________________________
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede
contener información privilegiada o confidencial y es para uso exclusivo de la
persona o entidad de destino. Si no es usted. el destinatario indicado, queda
notificado de que la lectura, utilización, divulgación y/o copia sin
autorización puede estar prohibida en virtud de la legislación vigente. Si ha
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente
por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential
information intended only for the use of the individual or entity named above.
If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this transmission in error, do not
read it. Please immediately reply to the sender that you have received this
communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
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 dont
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
[email protected]
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
