Thank you, Luis for the review and for agreeing to act as shepherd. I read through your write-up and this diff. I see you called out the IEEE802.1AX and IEEE802.1AB references, but I do not see that addressed in this diff or discussed here.
I don’t like sending up drafts that have identified or potentially identified issues if it can be avoided. In my reading of this draft, I feel these IEEE standards are informative in that I don’t need to understand them to be able to implement this YANG module. It sounds like you feel differently, Luis? Joe From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Date: Tuesday, May 28, 2024 at 04:48 To: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmuri...@telefonica.com>, opsawg@ietf.org <opsawg@ietf.org> Cc: draft-ietf-opsawg-teas-attachment-circ...@ietf.org <draft-ietf-opsawg-teas-attachment-circ...@ietf.org> Subject: [OPSAWG]Re: Sheperd write-up for for YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit) Hi Luis, Thank you for the review. Please see a diff to track the changes at: Diff: draft-ietf-opsawg-teas-attachment-circuit.txt - draft-ietf-opsawg-teas-attachment-circuit.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt&url_2=https://boucadair.github.io/attachment-circuit-model/boucadair-patch-5/draft-ietf-opsawg-teas-attachment-circuit.txt>. Please let us know if any further change is needed. See inline for more context. Cheers, Med De : LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmuri...@telefonica.com> Envoyé : lundi 27 mai 2024 16:55 À : opsawg@ietf.org Cc : draft-ietf-opsawg-teas-attachment-circ...@ietf.org Objet : Sheperd write-up for for YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit) Dear authors, With some delay (apologies for that), I have provided the shepherd’s review of draft-ietf-opsawg-teas-attachment-circuit. The review is available here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/shepherdwriteup/ [Med] Thanks. I guess the writeup can indicate that this spec was presented to TEAS and that it was WGLCed there as well. Thanks. Apart from the review provided I have some comments / suggestions / clarification questions: · The title quotes ‘Attachment Circuits’, while in the text is not quoted at all. Probably better to follow the same approach always. [Med] It is quoted to make as-a-service refers to the AC, not circuit. Changed one occurrence in the main text for consistency. · Scope section refers to ancillary nodes, but the document does not include any definition of what an ancillary node refers to [Med] Ancillary is used in reference to a connectivity service. An example is https://datatracker.ietf.org/doc/html/rfc9543#name-ancillary-ces. · Section 1.1: s/… while the underlying link is referred to as “bearers” /… while the underlying link is referred to as “bearer” [Med] ACK. · Regarding the terminology to Network Slice service, not clear if should be prefixed as IETF Network Slice service (or not). Necessary to be aligned with the criteria that could be defined in TEAS WG. [Med] ACK, although the AC can be used for other slice types. · The document includes references to the other attachment circuit documents. I guess all these references should be updated to the corresponding RFC during the publication process. It could be interesting to add a note for the RFC editors to note this fact. [Med] I don’t think a note is needed here because the set of I-Ds will progress as a cluster. The RFC Editor will take care of that. Thanks. · Section 2. Definition of Bearer. It is stated that one or multiple technologies can be used to build a bearer. It is not clear what are the implications of this. Does it imply concatenation? The YANG model describe applies to bearer from multiple technologies concatenated? An example of this would be beneficial. [Med] Added the example of LAG. · Section 4.1, last paragraph about protection. It is mentioned that the customer may request protection schemes when endpoints are terminated by the same PE, but the customer in principle does not have any view of the provider network. Is that right? If so, how the customer knows that endpoints are on the same PE? [Med] The customer indicates that type, without calling it out a specific PE. Updated the text to make it clear that the provider will select the PE. · Section 4.2. s/ This includes the flow put in place for the provisioning of network services … / This includes the workflow put in place for the provisioning of network services … [Med] Sure. Done. · Sentence above Figure 3. s/Figure 3 shows the positioning of the AC service model is the overall … /Figure 3 shows the positioning of the AC service model in the overall … [Med] ACK. · The ietf-bearer-svc model has associated a customer-name. Does it mean that the bearer is bound to only one customer? Why a bearer is associated to a customer? What about the case of a shared medium (e.g., wifi link)? [Med] This data node is optional. Even for WLAN, a customer may be associated with a channel. · I think it is already reflected in the security considerations, but the reference of bearer or AC to customer could create privacy risks. [Med] Yes · Bearer-parent-ref, AC-parent-ref. Probably the notion of parent should be defined in terminology section. [Med] Done. · ‘test-only’ can be a source of attacks and privacy risks. Probably it should be discussed in the security considerations. [Med] Updated accordingly. · The full tree is documented in [AC-svc-tree] which is a personal report. I think it would be necessary to guarantee persistency on this by moving this to an IETF repository (or even the wiki). · Below Figure 5, It is mentioned that each AC is identified with a unique name within a domain. Are we considering here administrative domains? Unique within a service provider? Which kind of domains apply to this restriction? [Med] We meant provide domain. Updated accordingly. · The following paragraph mentions that the AC service model uses groupings and types defined in the AC common model. It would be convenient to list what groupings and types are used, so that it is evident to the reader those. This also would help to identify future augmentations or modifications. [Med] Added a list. · Figure 6, valid-provider-identifiers. [Med] Can you please clarify the comment here? Thanks. · ‘peer-SAP’. Since the document covers both perspectives (customer one and service provider one) it could be confusing in some cases the notion of peer-SAP. So it could be clarifying in some cases to refer to it as peer-SAP from the customer perspective, and so on. [Med] Good point. Added a clarification this is from the perspective of the provider network. Apologies again for the delay, hope the comments are helpful. Best regards Luis _____________________________________ Luis M. Contreras Transport & IP Networks Systems and Network Global Direction Telefónica I+D / CTIO unit / Telefónica Distrito Telefónica, Edificio Sur 3, Planta 3 28050 Madrid España / Spain Mobile: +34 680 947 650 luismiguel.contrerasmuri...@telefonica.com<mailto:luismiguel.contrerasmuri...@telefonica.com> ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição ____________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
