Thanks Behcet.
The "n.d." is an artefact of xml2rfc. I'll leave that for the RFC Editor to worry about.
We could add an abreviations section if anyone feels strongly (I don't, and I'm not looking for extra work :-)
Cheers,
Adrian
On 06/07/2023 18:10 BST Behcet Sarikaya via Datatracker <noreply@xxxxxxxx> wrote:Reviewer: Behcet SarikayaReview result: Ready with NitsI am the assigned Gen-ART reviewer for this draft. The General AreaReview Team (Gen-ART) reviews all IETF documents being processedby the IESG for the IETF Chair. Please treat these comments justlike any other last call comments.For more information, please see the FAQ atDocument: draft-ietf-teas-rfc3272bis-??Reviewer: Behcet SarikayaReview Date: 2023-07-06IETF LC End Date: 2023-07-11IESG Telechat date: Not scheduled for a telechatSummary:This document is a bis document intended to obsolete RFC3272 thatdescribes the principles of traffic engineering in the Internet. Since RFC3272published in 2003 is an informational RFC, this document's status is also setas informational RFC although it could have been a BCP. The document gives anice account of all changes that happened on traffic engineering since the past20 years. I specifically looked for IPv6, YANG to replace SNMP, SDN,Virtualization and also Quic and MPTCP in the context of ATSSS, they were allvery well covered. The document is very well written. What I couldn't find arethe coverage of cloud issues, edge computing, data center interconnect whichare just mentioned and identifier locator separation work not even mentioned.Major issues:N/AMinor issues:N/ANits/editorial comments:The last two references FT01 and GRPC have n.d. meaning no date?The document has a nice terminology section 1.4 and most acronyms have beenspelled out but there is no acronyms section
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call