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/ 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. * Scope section refers to ancillary nodes, but the document does not include any definition of what an ancillary node refers to * Section 1.1: s/... while the underlying link is referred to as "bearers" /... while the underlying link is referred to as "bearer" * 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. * 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. * 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. * 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? * 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 ... * 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 ... * 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)? * I think it is already reflected in the security considerations, but the reference of bearer or AC to customer could create privacy risks. * Bearer-parent-ref, AC-parent-ref. Probably the notion of parent should be defined in terminology section. * 'test-only' can be a source of attacks and privacy risks. Probably it should be discussed in the security considerations. * 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? * 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. * Figure 6, valid-provider-identifiers. * '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. 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
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
