Thanks Donald for detailed valuable review and thanks Jensen to address Donald's comments. -Qin (on behalf of chairs) -----邮件原件----- 发件人: alto [mailto:alto-bounces@xxxxxxxx] 代表 Donald Eastlake 发送时间: 2021年12月1日 11:47 收件人: Jensen Zhang <jingxuan.n.zhang@xxxxxxxxx> 抄送: Last Call <last-call@xxxxxxxx>; draft-ietf-alto-cdni-request-routing-alto.all@xxxxxxxx; IETF ALTO <alto@xxxxxxxx>; int-dir@xxxxxxxx 主题: Re: [alto] Intdir telechat review of draft-ietf-alto-cdni-request-routing-alto-17 Hi Jensen, Thanks for your agreeable response. I'm happy with your re-wording of the second paragraph of Section 3.7.1. Assuming the draft is changed as described in your response, I consider all my comments to have been resolved. Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@xxxxxxxxx On Tue, Nov 30, 2021 at 8:48 AM Jensen Zhang <jingxuan.n.zhang@xxxxxxxxx> wrote: > > Hi Donald, > > Many thanks for your review. Please see my responses inline. > > Thanks, > Jensen > > > On Sat, Nov 27, 2021 at 10:19 AM Donald Eastlake via Datatracker <noreply@xxxxxxxx> wrote: >> >> Reviewer: Donald Eastlake >> Review result: Ready with Issues >> >> I am an assigned INT directorate reviewer for >> draft-ietf-alto-cdni-request-routing-alto-17. These comments were >> written primarily for the benefit of the Internet Area Directors. >> Document editors and shepherd should treat these comments just like >> they would treat comments from any other IETF contributors and >> resolve them along with any other Last Call comments that have been >> received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/. >> >> Based on my review, if I was on the IESG I would ballot this document >> as NO OBJECTION. >> >> The following are issues I found with this document that SHOULD be >> corrected before publication and some comments: >> >> I am not particularly familiar with the technology in this draft os I may >> have missed things. >> >> Abstract: I believe it should say "the exact protocol is not specified" >> adding "not". > > > Thanks for the catch. We will fix it. > >> >> >> Section 3.7.1: The second paragraph of this section is one very long >> sentence that I found confusing and which may be inconsistent. Perhaps a >> structured list would be better than simple text. > > > Good suggestion. How about the following restructure: > > OLD: > > Specifically, the IRD announces two network maps, one CDNI > Advertisement resource without dependency, one CDNI Advertisement > resource depending on a network map, one filtered CDNI Advertisement > resource to be defined in Section 5, one property map including > "cdni-capabilities" as its entity property, one filtered property map > including "cdni-capabilities" and "pid" as its entity properties, and > two update stream services (one for updating CDNI Advertisement > resources, and the other for updating property maps). > > NEW: > > Specifically, the IRD announces nine information resources as follows: > > * two network maps > * one CDNI Advertisement resource without dependency > * one CDNI Advertisement resource depending on a network map > * one filtered CDNI Advertisement resource to be defined in Section 5 > * one property map including "cdni-capabilities" as its entity property > * one filtered property map including "cdni-capabilities" and "pid" as its entity properties > * two update stream services > + one for updating CDNI Advertisement resources > + one for updating property maps > >> >> >> Section 6.1.1.2: Seems a bit imprecise. I suggest adding at the end "as a >> decimal number without leading zeros". > > > Very good suggestion. We will add it. > >> >> >> I was favorably impressed by the relatively complete information included >> for the Authors in the Authors' Addresses Section. I wish more drafts did >> this. > > > Thanks ;) > >> >> >> The following are minor issues (typos, misspelling, minor text >> improvements) with the document: >> >> PID should be expanded on first use. Although, as far as I can see, other >> acronyms are appropriately expanded on first use. the document might benefit >> from a terminology section (maybe 1.1 or 2.3) as not everyone may read the >> document sequentially and remember all the expansions. > > > Reasonable suggestion. We will add such a section in the coming revision soon. > >> >> >> Section 2.2, 2nd *'ed paragraph, "ALTO maps can be signed" adding "be". > > > Thanks for the catch. > >> >> >> Section 3.6: I don't think the following text is needed and it could be >> deleted. It merely expresses the default that later IETF documents can >> modify earlier IETF documents. >> There may be other >> documents extending BaseAdvertisementObject and additional CDNI >> capabilities. They are outside the scope of this document. To >> support them, future documents can extend the specification defined >> in this document. > > > Agree. > >> >> >> Section 3.7.1: /// -> // >> >> Section 6.2.1: "to define" -> "defining" > > > Thanks. Will fix. > >> >> >> Section 10: It is common to include the same information for Contributors as >> is included for Authors in the Authors' Addresses section but that has not >> been done. > > > Good catch. We will definitely fix this issue. We were using kramdown-rfc2629, which seems not to support the Contributors section yet. But it should work by embedding XML manually. > >> >> There are a few addition suggestions that I will send directly to the >> authors. >> >> Really trivial: when you have >> "xyz": stuff >> for various values of xyz and stuff, there is no consistency in >> whether or not there is a space before the colon. > > > Ha, you are right. We will fix this trivial issue. > >> >> >> >> >> _______________________________________________ >> alto mailing list >> alto@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list alto@xxxxxxxx https://www.ietf.org/mailman/listinfo/alto -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
