Hello Med: It took a few publications but I believe your comments related to the document are now addressed. Please let us know. Again many thanks for your in-depth review ! A bientôt; Pascal > Le 10 sept. 2024 à 15:46, Mohamed Boucadair via Datatracker <noreply@xxxxxxxx> a écrit : > > Reviewer: Mohamed Boucadair > Review result: Has Issues > > Hi authors, > > Many thanks for the effort put into this document along several years. > > I reviewed the document from an ops-dir review, but I also have more general > comments: > > # OPS > > Although mentioned too late in the document (security section), the document > says explicitly that it does not include any ops considerations. It is fair to > set that scope given the rich content of the document and main objective to > describe technologies themselves. However, such mention should be included > early in the document. > > There are ops considerations that are applicable to scheduling resources in > general, path computation, or synchronization matters. Nevertheless, given that > the objectives is not to provide recommendations about the various > technologies, I would not ask the authors to add NEW text with these > considerations for each technology. That would be over-specifying here. > Instead, the authors may include relevant pointer are readily available. This > is not even needed with the suggested note about ops considerations are not in > scope. > > The document includes an OAM section for one specific technology, but that > section is too brief and does include up-to-date specific pointers. Cited > documents are generic or expired since a while. > > # Generic > > ## Target audience/consumer of this material > > I know that it is frustrating to receive this kind of comments after many years > of effort maintaining this doc, but I sincerely think that the document lacks > some words to explain the rationale of collecting this material and how this is > intended to be used in the IETF. This clarification is specifically needed as > some of the text needs some refresh (see next point). Including such text will > also help understanding the value of publishing this as an RFC (which I suspect > this might be questioned by some). > > ## Stale/Need to refresh > > The text includes stale text (e.g., pointer to specs that expired several years > ago, text that won't age well, text that need to be refreshed to reflect > progress (or lack of progress in cited SDOs). I tagged some off those in my > review, but I can't claim that I tagged all of them. > > The text can be cleaned in several places to avoid what can be seen as > speculating or over-selling some efforts. > > ## Liaise with material owners > > The material included in various sections is owned by other SDOs. Unless this > is already done, it would be reasonable to send LSes to at least 3GPP/IEEE to > review relevant sections. > > # Detailed review > > A more detailed review can be found using the following links: > > * pdf: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-raw-technologies-10-rev%20Med.pdf > * doc: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-raw-technologies-10-rev%20Med.doc > > Feel free to grab whatever you think useful for the document. > > Hope this helps. > > Cheers, > Med > > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
