Re: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-20.txt

[Adrian Farrel <[e-mail]>]

Hi Med,

Thanks for this.

> (1) The change you made in Section 6.2 (which is incomplete s/rely/rely
upon)
>
> CURRENT: 
>      exposed to the customer.  (Note - a customer should not rely
>      network information not exposed via the IETF Network Slice Service
>      Interface, even if that information is available.)
>
> attracted my attention to the note itself. 

Ah, a useful typo!

> I'm afraid that this note is confusing/restrictive as the slice service
request
> may itself be fed by information that is retrieved using other APIs
exposed
> to the customer. I'm specifically thinking about the ACaaS interface that
> can also be exposed separately. De we really need to have that note?

Well, the text has been there a while. It pre-dates WG adoption. In all
versions of the draft, the text read "should not use" until John's review.
I wasn't party to the discussions that generated this text, so I don't know
it's purpose.
But I suspect I can guess that the idea is that a slicing customer should
not be obtaining network information (such as topology and status) outwith
the control of the network operator. The customer cannot know he operator's
policies and attempt to prejudge or influence how the operator chooses to
provide a service.

Maybe the solution here, to cover your point and what I think may underlie
the existing text, is to change to...

   (Note - a customer should not rely
    network information not exposed directly by to the
    customer by the network operator, such as via the
    IETF Network Slice Service Interface.)

> (2) I wonder whether it is possible to include an informative reference to
>  draft-boucadair-teas-ietf-slicing-overview so that readers of the
framework
>  have an entry point to other related activities in the IETF. 

I support what you are trying to do with your draft.

This draft currently says, "At this stage, it is inappropriate to cite any
of these proposed solutions that are currently work in progress and not yet
adopted as IETF work." I stand by that: it is unfortunate that in many cases
people have used informative references to attempt to justify adoption of
their proposed solution when there is a large set of competing drafts.
Although your work aims to be comprehensive, it would, in this case be just
a proxy reference to individual proposals.

> (3) Please find some very minor nits: 

Nits very welcome and fixed.

Best,
Adrian