Skip to main content

Last Call Review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-11
review-ietf-opsawg-ac-lxsm-lxnm-glue-11-genart-lc-enghardt-2024-12-06-00

Request Review of draft-ietf-opsawg-ac-lxsm-lxnm-glue
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-12-09
Requested 2024-11-25
Authors Mohamed Boucadair , Richard Roberts , Samier Barguil , Oscar Gonzalez de Dios
I-D last updated 2024-12-06
Completed reviews Opsdir Last Call review of -10 by Ron Bonica (diff)
Rtgdir Early review of -09 by Gyan Mishra (diff)
Rtgdir Early review of -06 by Gyan Mishra (diff)
Yangdoctors Early review of -04 by Martin Björklund (diff)
Secdir Last Call review of -11 by Prachi Jain (diff)
Genart Last Call review of -11 by Reese Enghardt (diff)
Assignment Reviewer Reese Enghardt
State Completed
Request Last Call review on draft-ietf-opsawg-ac-lxsm-lxnm-glue by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/ZWjyh21vCTxF3YZcMqB8oGKoTpo
Reviewed revision 11 (document currently at 13)
Result Ready w/nits
Completed 2024-12-06
review-ietf-opsawg-ac-lxsm-lxnm-glue-11-genart-lc-enghardt-2024-12-06-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-opsawg-ac-lxsm-lxnm-glue-11
Reviewer: Reese Enghardt
Review Date: 2024-12-06
IETF LC End Date: 2024-12-09
IESG Telechat date: Not scheduled for a telechat

Summary: The document is fairly clear and concise. I have a few clarification
questions and suggestions to make the document more accessible.

Major issues: None.

Minor issues:

Section 1:

Please consider a sentence to explain the high-level motivation for this
document. Is it to allow VPNs to be modeled as Attachment Circuits (ACs), where
ACs are means to attach routers to other routers or end systems?

Section 2:

Even though the term "Attachment Circuit" is defined in the referenced draft
I-D.ietf-opsawg-teas-attachment-circuit, please consider providing the
definition in this document, as it appears fundamental to understanding the
document.

Section 4.1:

As Section 4 is titled "Sample Uses of the Data Models", and this document is
about VPNs, I expected an example that mentions VPNs, but I didn't see any
explicit mention of a VPN in this section. Could any of the ACs presented in
this example be used to host a VPN, if defined using the data model introduced
in this draft? Please consider adding a brief explanation of how does the data
model introduced in this draft relates to the example.

Section 4.2:

"Customers can request a bearer ("ietf-bearer-svc") or an attachment circuit
("ietf-ac-svc") to be put in place, and then refer to that bearer or AC when
requesting VPN services that are bound to the bearer or AC ("ietf-ac-glue")."

From this text, it sounds like bearer or AC are interchangeable, yet, according
to Section 3, ietf-ac-gue does not reference ietf-bearer-svc. In the model
itself, I see that the title of ietf-ac-svc mentions both Bearer and ACs. So,
is it still necessary to reference ietf-bearer-svc in this section?

Nits/editorial comments: None.