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> 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> *On Behalf Of *Vishnu Pavan Beeram
> *Sent:* 28 June 2022 10:07
> *To:* TEAS WG <teas@ietf.org>
> *Cc:* TEAS WG Chairs <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
> https://www.ietf.org/mailman/listinfo/teas
>