Hi Mach, Thank you for the review. The changes to address the review can be tracked at: https://tinyurl.com/sap-latest Please see inline. Cheers, Med > -----Message d'origine----- > De : last-call <last-call-bounces@xxxxxxxx> De la part de Mach > Chen > Envoyé : jeudi 12 mai 2022 11:11 > À : rtg-dir@xxxxxxxx > Cc : draft-ietf-opsawg-sap.all@xxxxxxxx; opsawg@xxxxxxxx; last- > call@xxxxxxxx > Objet : [Last-Call] RtgDir Last Call review: draft-ietf-opsawg- > sap-04 > > 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 > http://trac.tools.ietf.org/area/rtg/trac/wiki/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-ietf-opsawg-sap-04 > Reviewer: Mach Chen > Review Date: 2022/05/15 > IETF LC End Date: > Intended Status: Standards Track > > Summary: > I have some minor concerns about this document that I think should > be resolved before publication. > > Major Issues: > None > > Minor Issues: > 1. Section 2, the definition of Service Attachment Point (SAP) is > hard to understand here, the definition depends on the definition > of "service's endpoint" and "TP" that is not defined in the > document or lack of references(if defined in other documents). > More text needed here and it's better to make it consistent with > the definition in other places (e.g., Introduction section). [Med] Updated the text to: NEW: Service Attachment Points (SAPs): An abstraction of the network reference points (e.g., PE side of an AC) where network services can be delivered and/or being delivered to customers. > > 2. Section 3, > " The > model is also used to retrieve the network points where a > service is > being delivered to customers." > What's the meaning of the "network points" here? Is it a node, > link, interface or something else, some clarification needed here, > or using a more specific and well-known term here. > [Med] An example was added to updated definition provided above. > 3. Section 4, " Also, the SAP is not a tunnel termination point > (TTP) (Section 3.6 of > [RFC8795]) nor a link." Why need to state this here, maybe it's > better to move it to the place of the definition of "SAP". [Med] We prefer to maintain it here as this section is about positioning the model vs. existing models. > > 4. identity basic-connectivity { > base vpn-common:service-type; > description > "Basic IP connectivity. This is, for example, a plain > connectivity offered to Enterprises over a dedicated > or shared MPLS infrastructure."; Since it's a "IP > connectivity", why emphasize that it is over an "MPLS" > infrastructure? > [Med] That was just an example. > Nits: > 1. Abstract section, the second sentence of paragraph, s/ The > Service Attachment Points/SAPs [Med] OK 2. Section 1, the last 3rd para, > it's better to add references when mention L2VPN and L3VPN [Med] Added a pointer to RFC4026. 3. > Section 3, suggest to add a reference to EVPN. [Med] Several EVPN-related are provided in Section 5 with explicit association with the EVPN flavor. > 4. Section 5, suggest to add the references to LAG, IRB. [Med] OK > 5. identity virtual-network, suggest to copy the description of > "Virtual Network" from RFC 8453. [Med] Went with the following: OLD: "Virtual network."; NEW: "Virtual network. Refers to a logical network instance that is built over a physical network."; > 6. It's better to add more text to the description of identity > phy, loopback, lag and irb. [Med] These are well-known and well-established. I don't think we need to say much here, but will see. Thanks. > > Best regards, > Mach > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call _________________________________________________________________________________________________________________________ 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 https://www.ietf.org/mailman/listinfo/last-call
