Re: [Teas] WG adoption poll: draft-contreras-teas-slice-nbi-06

Hi Greg, Adrian, all,

I completely agree with you analysis and I’m in favor of merging the two documents…otherwise this discussion will pop up again and again as soon as will forget the relationship between them or a newcomer will read them.

Cheers,
Daniele

From: Teas <teas-bounces@ietf.org> On Behalf Of Greg Mirsky
Sent: den 3 juli 2022 20:55
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: Vishnu Pavan Beeram <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>; TEAS WG Chairs <teas-chairs@ietf.org>
Subject: Re: [Teas] WG adoption poll: draft-contreras-teas-slice-nbi-06

Thank you Adrian for bringing up the question of the relationship between draft-contreras-teas-slice-nbi and draft-ietf-teas-ietf-network-slice-nbi-yang. I agree with you that there are commonalities. At the same time I find substantial value in draft-contreras-teas-slice-nbi that, in my understanding, explains the motivation for the YANG data model draft. It seems to me that it would be beneficial to clearly establish that relationship between two documents. While there are many ways, I can consider two options:

  *   adding normative cross-references
  *   merging drafts
As a minor comment, I think that the use of references in draft-contreras-teas-slice-nbi needs more attention.

Regards,
Greg

On Sat, Jul 2, 2022 at 4:32 PM Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:
Hi,

(Not late with this review!)

I only have one question about supporting the adoption of this document
and that is to wonder whether the work is overtaken by events. We
already have work progressing developing and specifying the IETF Network
Slice Service Interface YANG model in draft-ietf-teas-ietf-network-
slice-nbi-yang. That YANG model is surely based on discussions that
arise from this work, and I am not doubting the value of those
discussions. But I don't quite understand why we need to pursue this I-D
towards an RFC when it's principal purpose is surely to shape the
content of the YANG model. Have I missed the purpose of this draft?

Comments below that arose as I read the document. I don't believe that
any of them needs to be fixed before adoption (if adoption is decided by
the WG).

Cheers,
Adrian

== Major (not actually blocking adoption, but worrying)

I really wish we could get away from the "Northbound Interface"
terminology. While it is OK as a term when it is given the context
("northbound of what?") as this document does in the Abstract, it is
possible to quickly degrade to just talking about "the NBI" which
becomes problematic because your NBI is my SBI. That is why the
framework document now talks about the "IETF Network Slice Service
Interface." I think that this document (and especially section 3) should
align with that terminology. That is not a change that particularly
blocks adoption, but it is a change that I would like to see made at
some point. As the authors say in Section 2...
   The terminology in this draft will be aligned in forthcoming versions
   with the final terminology selected for describing the notion of IETF
   network slice when applied to IETF technologies, as defined in
   [I-D.ietf-teas-ietf-network-slices] .
...so, hey, why not do that now?

== Minor (not blocking adoption, but need to be fixed at some point)

Section 3 has...

   The functionality supported by the NBI depends on the requirements
   that the slice customer has to satisfy.

I really don't understand this! The customer has to satisfy
requirements? Who places those requirements on the customer?

Would "objectives" be a better word than "requirements"?

But perhaps you mean...

   The functionality supported by the NBI depends on the requirements
   that the slice customer places on the network.

But even then, I am not sure it is right. Surely the functionality
supported by the NBI depends on the features that the operator chooses
to let the NSC expose to the customer. Of course, to be sensible, we
need the NBI to be useful so we are hoping that the operator will
expose features that the customer finds useful to meet its objectives?

---

I appreciate the nominal placeholder in Section 4.6, and I see the
short list (one member) of possible other use cases that could be added.
It is obvious that any new use case would be added as a subsection of
Section 4, so perhaps replace the current Section 4.6 with...

4.6.  Data-Center Interconnection

   Details of this sue case to be supplied in a future revision of this
   document.

...Or, alternatively, just delete the section.

== Nits (definitely not blocking adoption)

Please move to using the up-to-date version of the BCP14 boilerplate.

---

It would be good to insert some more references into the text.

---

There are a number of terms (inherited from GSMA etc.) that need to
at least have their abbreviations expanded. It might be nice to list
them out early on and supply a reference for each term.

---

Try to avoid saying "draft" in the body of the text as it will cause
confusion if/when you publish as an RFC. Better to say "document".

From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> On Behalf Of Vishnu Pavan Beeram
Sent: 28 June 2022 10:07
To: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Cc: TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>
Subject: [Teas] WG adoption poll: draft-contreras-teas-slice-nbi-06

All,

This is start of a *two* week poll on making
draft-contreras-teas-slice-nbi-06 a TEAS working group document
[https://datatracker.ietf.org/doc/html/draft-contreras-teas-slice-nbi-06].

Please send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document. If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends July 12th.

Thank you,
Pavan and Lou

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas