Last Call Review of draft-ietf-opsawg-ntw-attachment-circuit-12
review-ietf-opsawg-ntw-attachment-circuit-12-rtgdir-lc-halpern-2024-08-14-00

Request Review of draft-ietf-opsawg-ntw-attachment-circuit-12
Requested revision 12 (document currently at 13)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2024-08-16
Requested 2024-07-31
Requested by Mahesh Jethanandani
Authors Mohamed Boucadair , Richard Roberts , Oscar Gonzalez de Dios , Samier Barguil , Bo Wu
I-D last updated 2024-08-14
Completed reviews Rtgdir Last Call review of -09 by Gyan Mishra (diff)
Rtgdir Early review of -05 by Gyan Mishra (diff)
Yangdoctors Early review of -04 by Martin Björklund (diff)
Opsdir Last Call review of -12 by Giuseppe Fioccola (diff)
Rtgdir Last Call review of -12 by Joel M. Halpern (diff)
Comments 
I would like OPS Directorate's views on the applicability of this YANG module. RTG reviewed this document, but I would like to draw their attention to the comment below.

I would like the directorates to comment on Section 5.3, Provisioning Profiles, and their view on the routing-profile-identifiers within the YANG model both from an operations and routing perspective. Note, that the module identifies certain parameters for each routing protocol BGP, OSPF, ISIS, and RIP at a *network* level, not at a device level. That means each AC gets to define its own "routing profile". How is an operator supposed to read (and use) these parameters, considering that the device might have its own configuration for those routing protocols?

Gyan, since you have reviewed this document, could you update the review to address the above comment. Thanks.
Assignment Reviewer Joel M. Halpern
State Completed
Request Last Call review on draft-ietf-opsawg-ntw-attachment-circuit by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/vbEWds2sukbhsomERLr4XD6UmMM
Reviewed revision 12 (document currently at 13)
Result Ready
Completed 2024-08-14
review-ietf-opsawg-ntw-attachment-circuit-12-rtgdir-lc-halpern-2024-08-14-00
Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-name-version
Reviewer: your-name
Review Date: date
IETF LC End Date: date-if-known
Intended Status: copy-from-I-D

Summary:
Choose from this list...

No issues found. This document is ready for publication.
    I have a few minor comments that should be considered.

This is a truly impressive piece of work.  The editors have pulled together
information from a myriad sources into a usable (if massive) YANG module that
addresses the range of needs very well.

Major Issues: N/A

Minor Issues:
    I note that section 5.1 in discussing parent relationships specifies that
    if a parent AC is deleted, all the child ACs MUST be deleted.   Given that
    there is no reference from a parent to its children (unless I missed it),
    it seems to this reader that it would really help implementors to tell them
    how this is to be done?  Are all children to be delted first, and the
    client give an error if there are any active children?  Is the client to
    silently find and delete all ACs which point to the deleted AC as a parent?
     Or some other means?

   In section 5.2 (References) in describing the groupings the tree diagram
   shows a number of peer entities.  However, unless I am misreading the YANG,
   they are, in almost all cases, actually nested.  Was this a deliberate
   simplification, on artifact of the tree generation tool, or an error in my
   reading?

    I note that the document refers to RIP in multiple places.  Unless I missed
    something, this references RIPv2, but not RIPng (RFC 20808).  I can imagine
    reasons for such an omission.  If there is a good reason, then please state
    it.  Otherwise, sorry, please also cover 2080.