Ballot for draft-ietf-pim-igmp-mld-proxy-yang
Yes
No Objection
Abstain
Note: This ballot was opened for revision 07 and is now closed.
I concur with Eric: "YANG" is an acronym, so it should be in all-caps.
OLD DISCUSS: Should these not be a rw value? +--ro filter-mode enumeration +--ro group* [group-address] +--ro group-address +--ro source* [source-address] The example in the appendix shows these values being set (so rw): "group-address": "233.252.0.23", "filter-mode": "include", Answer: no these are inherited from the interface above it. NITS: The mld-version represents version of MLD protocol, and default value is 2. The "2" here is a link to Section 2, which I assume is not intended to be a link. The mld-version represents version of MLD protocol Missing "the" before version.
Thank you to Klaas Wierenga for the SECDIR review. Section 5. The following description is in include in the text a few times: “Modifying the configuration may cause the ... interface to be deleted or reconstructed.” What does it mean for the interface to be “reconstructed”?
Firstly, thank you to the authors for this document. Other than Paul's point I don't have anything to add.
Thanks for working on this specification. This specification says - "occasionally implemented parameters are modeled as optional features in this model, while the rarely implemented parameters are not included in this model and left for augmentation.” It is very vague in describing the criteria of selecting what is occasionally and rarely implemented parameter. So, one might pick one parameter as rarely implemented and the same parameter can be picked as occasionally implemented by others. I would suggest to either describe it more or point to something where this was discussed. It might just say - at this point this is the WG’s concensus on the list of rarely and occasionally implemented parameters and features.
# Éric Vyncke, INT AD, comments for draft-ietf-pim-igmp-mld-proxy-yang-08 CC @evyncke Thank you for the work put into this document. As I cannot agree with the section 2.3, I am balloting ABSTAIN as it does not fit any DISCUSS criteria (which would be my personal choice). Please find below one non-blocking COMMENT points (but replies would be appreciated about my ABSTAIN), and one nit. Special thanks to Stig Venaas for the shepherd's detailed write-up including the WG consensus *but* missing the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Section 2.3 Having two different branches for MLD and IGMP can only lead to operational difficulties as two branches need to be handled. Operators won't have a easy way to manage both MLD and IGMP in the same network. I expressed *exactly* the same point for RFC 8652. Isn't it defeating the purpose of having a data model ? ## NITS ### Yang in uppercase Please use YANG in all uppercase (notably in the RFC title) as it is an acronym. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
Updated position. Thanks for addressing my discuss and comments.