Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-teas-common-ac-14: 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-opsawg-teas-common-ac/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-teas-common-ac-14 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Reza Rokui for the shepherd's detailed write-up including the WG consensus *but* the justification of the intended status is rather light: being "valuable" is not enough to be a "standard". I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) Thanks for using SVG graphics, it makes reading the HTML rendering much easier and nicer. ### Abstract Should 'model' be used rather than 'module' in `The document specifies a common attachment circuits (ACs) YANG module` in order to be consistent with the title ? I understand that a model can consist of a single module. ### Section 1 Should `ancillary node` be better explained as it can mean multiple things depending on the context? Figure 1, when the text writes `The same CE may terminate multiple ACs.` it would help if the text mentioned CE3 & CE4 and the associated bearer (assuming that `b*` is for a bearer). ### Section 2 When defining "bearer", please associate the previously defined terms (CE, CPE) with `customer node`. ### Section 3 Not really about this I-D, but I find the use of `ietf-ac-glue` rather than 'ietf-ac-bind' a little too trivial especially when the text is about `To bind Layer 2 VPN` ;-) ### Section 4 Thanks for splitting the whole tree in parts, it helps. ### Section 4.1 It is rather unclear what `server` means in this document, even if I can guess some controllers in the SP domain. ### Section 4.3 Should there be a `*l3*-tunnel-type` in addition to `*l2*-tunnel-type` ? Should the layer of the next hop be specified in `local-defined-next-hop`? Should there be reference to `UNI`and `NNI`? About figure 5 explanations about ipv6-connection, should there be a possibility for multiple IPv6 addresses per service ? Should there be SLAAC for dynamic address allocation ? Should there a choice on how to authenticate OSPFv3 either RFC 4552 or RFC 7166 ? ### Section 5 In the vxlan grouping, the modules writes `"Specifies the VXLAN access mode. By default, the peer mode is set to 'static-mode'.";` but I see nothing in the YANG module to set a default (unsure whether it is possible though). ## NITS (non-blocking / cosmetic) s/Layer 2 VPN/layer-2 VPN/ ? same for layer 3 of course **** _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
