Hi Michael,
On Tue, Nov 12, 2024 at 10:00 PM Michael Scharf via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Michael Scharf
Review result: Ready with Nits
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
This document specifies a YANG data model for PCEP as application protocol.
This document is well-written and I have not found any specific issues related
to transport protocols.
However, I'd like to note that it is quite hard to review in detail a complex
YANG data model that has apparently not been implemented and tested at all.
>From a high-level point of view, there may be two nits:
1. It is not clear to me why Section 3.3 is needed.
Dhruv: It is a practice that is quite common as it helps track the references as they move from draft to RFCs. It also helps avoid the idnits warning one would get saying that the reference is not used as idnits does not consider the use in the YANG.
2. Some design choices for data types in the YANG model are not really obvious.
For instance, "init-back-off-time" is uint16, but "max-back-off-timer" is
uint32. There are also quite a number of timer limites defined only as unit8.
In some cases, the chosen value ranges seem to originate from PCEP standard,
but I haven't been able to track down some other ones (well, as a
non-PCEP-expert). Similarly, it is hard to know if "counter32" will be
sufficient for some stat values.
Thanks!
Dhruv
Michael
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
