Hi Reese, Thank you for the review. All good points. A diff can be seen at: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-ac-lxsm-lxnm-glue.txt&url_2=https://boucadair.github.io/attachment-circuit-model/reese-review/draft-ietf-opsawg-ac-lxsm-lxnm-glue.txt. Please see inline for more context. Cheers, Med > -----Message d'origine----- > De : Reese Enghardt via Datatracker <noreply@xxxxxxxx> > Envoyé : vendredi 6 décembre 2024 21:54 > À : gen-art@xxxxxxxx > Cc : draft-ietf-opsawg-ac-lxsm-lxnm-glue.all@xxxxxxxx; last- > call@xxxxxxxx; opsawg@xxxxxxxx > Objet : Genart last call review of draft-ietf-opsawg-ac-lxsm- > lxnm-glue-11 > > > Reviewer: Reese Enghardt > Review result: Ready with Nits > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F% > 2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cmoh > amed.boucadair%40orange.com%7C728d3359fac84acc6ae708dd16381811%7C > 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638691152359928040%7CU > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIs > IlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda > ta=mv3%2FNKlWT2oqcxp1IxCtd4jar8iJL5zsQ76MHHuu7h0%3D&reserved=0>. > > 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? [Med] Added this NEW: This approach allows to separate AC provisioning from actual VPN service provisioning as further discussed in {{sep}}. > > 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. [Med] ACK. > > 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. [Med] VPN specific are discussed in 4.2. This section is to provide examples of ACs, first. > 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? [Med] Yes. Added this NEW: "These ACs can be referrenced in VPN services." > Please consider adding a brief explanation of how does the data > model introduced in this draft relates to the example. Note that we do have: An example to illustrate the use of the "ietf-ac-glue" model is provided in Appendix A. > > 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? [Med] Good catch. The bearer is indirectly referenced (via ac-ref). Cleaned the text. Thanks. > > Nits/editorial comments: None. > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
