Éric Vyncke has entered the following ballot position for draft-ietf-pce-pcep-yang-28: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing all my previous DISCUSS points and most of my COMMENTS (kept below for archiving) See also https://mailarchive.ietf.org/arch/msg/pce/qBCnhFw0AaSbuJPICGf_EVZrTGc/ ## COMMENTS (non-blocking) ### Section 1 I support Mahesh's DISCUSS, so I won't raise the following point to a block DISCUSS. Penultimate paragraph writes `PCEP statistics YANG module "ietf-pcep-stats" which provides statistics, counters and telemetry data`. While the last one has `The PCEP operational state is included in the same tree as the PCEP configuration consistent with NMDA`. For me, telemetry (and statistics) are crucial for operations, i.e., for the operational state. The end of section 1 appears to be self-contradicting... ### Section 4 `oper-status` is within the configuration part, shouldn't it be in another branch of the tree ? As I am not a YANG expert, I can be really wrong. It appears that the next sub-sections are describing part of the tree, please have some describing this approach (which I support) and have lead text per sub-section about which part(s) of the global tree is further detailed. ### Section 4.1.1 As I am not a PCEP expert, I really wonder why a PCEP speaker cannot be associated by multiple IP addresses (even if only being dual-stack) ### Section 5 As this YANG model has two modules (see above), should there be any text or consistency constraints about the future revision of one module, i.e., can one module be revised while the other is not ? ### Section 6 `Segment Routing in the IPv6 data plane is out of the scope of this document.`, this is a pity as SR-MPLS is included (see below). This makes the review and the ballot of this data model and the one for SRv6 very difficult... if the goal is to have some consistency between SR-MPLS & SRv6... ### Section 8.1 s/identity isis-area/identity is-is-area/ ? ### Section 12 s/We would like to thank/The authors would like to thank/ ? ### Appendix B Rather than having an example with IPv4 and adding `Similarly a PCEP session with IPv6 address between PCE (2001:DB8::3) and a PCC (2001:DB8::4) could also be setup` could this happen the other way ? IPv6 example and some text about IPV4 ? After all, the RFC will be published in 2025 ;-) Also, please use RFC 5952 for IPv6 addresses. ## NITS (non-blocking / cosmetic) ### YANG is in uppercase There is at least one occurrence of lowercase "yang" in the section 4.1, please use uppercase everywhere. _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
