[Teas] Re: WG Last Call: draft-ietf-teas-ns-controller-models (*3* weeks)

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Pavan,

Thanks  so much for your review. We will go through your comments during the next weeks, assuming that it will take some time to update due to the Summer period starting in a couple of weeks.

Thanks again,

Luis
________________________________
De: Vishnu Pavan Beeram <[e-mail]>
Enviado: lunes, 27 de julio de 2026 4:42
Para: Vishnu Pavan Beeram <[e-mail]>
Cc: TEAS WG <[e-mail]>; TEAS WG Chairs <[e-mail]>
Asunto: [Teas] Re: WG Last Call: draft-ietf-teas-ns-controller-models (*3* weeks)

AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

{as a WG participant}

Authors,

I've reviewed draft-ietf-teas-ns-controller-models-07 as part of the WGLC. Below are my comments -

---
Terminology Inconsistency:

Section 1 uses "transport slice" ("In order to facilitate the service exposure… of a transport slice") while the rest of the document consistently uses "IETF Network Slice" per RFC 9543. This should be harmonized. Is the term "transport slice" really needed (can it be removed)?
---

Editorial Nits:

1. Abstract: "constrain the implementation the IETF Network Slice Controller" → missing "of" before "the IETF"

2. Section 1: "the NSC assess and then identifies" → "assesses" (subject-verb agreement)

3. Section 2 (provider's view): "maintains an more network-centric view" → "a more"

4. Section 2 (provider's view): "the its realization" → "its realization"

5. Section 3, para 1: "The NSC then process customers requests" → "processes customer requests"

6. Section 3, para 3: "However, anything prevents that these modules could be separated components" → "nothing prevents these modules from being separate components"

7. Section 3.2: "if not filtering is applied" → "if no filtering is applied"

8. Section 4 (interface c): "considered in in [RFC9543]" → duplicate "in"

9. Section 6: Missing period at end of sentence.

10. Acknowledgments: "would like to thank (in alphabetical order) to" → remove "to"

11. Section 1: "the connectivity … are key" → "is key" (subject is "connectivity")

12. The same "implementation the IETF Network Slice Controllers" error from the Abstract is repeated at the end of Section 2.

13. Last author is listed as "Xufeng" (first name only) — should be "Xufeng Liu".

---

Gaps / Readability Issues:

1. Security Considerations: The current text only addresses the case where the Mapper and Realizer are separated. Should we also discuss:
   - Security of the customer-facing IETF Network Slice Service interface (authentication, authorization)
   - Multi-tenant isolation (preventing one customer from learning about another's slice topology/resources)
   - Protection against excessive or malicious slice requests (DoS)

2. Error handling: When the NSC interacts with multiple Network Controllers to realize a single slice and one controller fails, what is the expected behavior? Even as an informational document, some discussion of partial failure/rollback would be helpful for implementers.

3. Admission control / conflict resolution: The document mentions the NSC considers "the overall view of the network resources" but provides no discussion of how concurrent or conflicting requests from multiple customers are handled.

4. Mapping strategies: Section 3 mentions "mapping strategy 1:1/1:M/N:M" without explaining what these refer to in context. A brief clarification would improve readability.

5. The "Operator" entity shown in Figure 2 (with an interface to the NSC at the (b) level) is never explained in the text. What is this interface for, and how does it differ from the "Higher Level System" interface?

6. The "(b)" label appears twice in Figure 2 — once between Mapper and Realizer, and once on the Operator interface. If both use the same model type, this should be stated explicitly.

7. The concept of "filtered topologies" is introduced in Section 3.2 without prior definition or reference. A reference or a sentence explaining what filtering means in this context would help.
---

With the editorial fixes and some expansion of the Security Considerations, the document should be ready for publication.

Regards,
-Pavan

On Fri, Jul 10, 2026 at 3:29 PM Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>> wrote:
All,

This starts a three-week working group last call on
https://datatracker.ietf.org/doc/draft-ietf-teas-ns-controller-models

The working group last call ends on July 31st 2026.
Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Note: There is No IPR disclosed for this document.

Thank you,
Pavan
_______________________________________________
Teas mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

________________________________

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