Hi Luis, Great thanks for this thorough review. Your comments will be attended in the next iteration of the draft. Best regards, Sabine & co-authors
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
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
