Re: [alto] Review for draft-ietf-alto-unified-props-new-12
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 On Behalf Of LUIS MIGUEL CONTRERAS MURILLO Sent: Monday, October 12, 2020 10:44 PM To: 'alto@ietf.org' 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
Re: [alto] Review for draft-ietf-alto-unified-props-new-12
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 On Behalf Of LUIS MIGUEL CONTRERAS MURILLO Sent: Monday, October 12, 2020 10:44 PM To: 'alto@ietf.org' 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 rul
[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 "t
