Hi Joe: Regarding your suggestion of creating a new section/subsection for the potential future work, here is my view. I feel that there are only two aspects mentioned in our draft that could involve future work: a) ability to handle the full TPN space (i.e. 14-bit TPN) supported by the G.709-2020 b) optimizing the label format to reduce the label size. I feel that a separate section would make sense only if provide one or more options for addressing these topics. In other words, just the listing the topics in a separate section doesn’t add much to the document. We could create a separate draft when the time to address these future items comes. What do you think? Regards, radha From: Joe Clarke (jclarke) <jclarke@xxxxxxxxx> Thanks for the figure updates. Any thoughts from the authors on splitting out the potential future work into its own section? I think it would add clarity but perhaps not enough to justify the work. Joe On 9/29/22, 12:42, "Radhakrishna Valiveti" <rvaliveti@xxxxxxxxxxxx> wrote: Hi Joe: Thanks for your review of the B100G applicability draft. I have taken your suggestions into account and uploaded v12 of our draft. Please let me know if any additional edits are needed. Regards, radha -----Original Message----- From: Joe Clarke via Datatracker <noreply@xxxxxxxx> Sent: Wednesday, September 28, 2022 9:29 AM To: ops-dir@xxxxxxxx Cc: ccamp@xxxxxxxx; Subject: Opsdir last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-11 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Reviewer: Joe Clarke Review result: Has Nits I have been tasked to review this document on behalf of the OPS DIR. I wouldn't say I'm an expert in this area, but overall I found the draft easy to read, and from an operations point of view I appreciate the succinct applicability summaries, as well as the points to future extensibility work (though I wonder if those deserve their own section for added clarity). On the nits side, I notice you compare your Figure 3 with the figure in Section 3 of RFC7138. However, you omit the notion of labeling the A, B, etc. with "OTN Switch", which I think would help. I'm also not sure what "3R" means here or in Figure 1 (but that is likely my lack of experience here). Finally, the two parts of Figure 3 seem to be showing both one-hop and multi-hop OTUCn links but you do not call that out as is done in RFC7138. |
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
