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

[[e-mail]]

Re-,

Thanks, Adrian. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Adrian Farrel <[e-mail]>
> Envoyé : jeudi 15 juin 2023 14:51
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> 'TEAS WG' <[e-mail]>
> Objet : RE: I-D Action: draft-ietf-teas-ietf-network-slices-20.txt
> 
> 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.)

[Med] This is better, thanks. Apologies for bringing this late in the process but it is mysterious how we don't pay attention to things that we read hundreds of time. 

> 
> > (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.
> 

[Med] I hear you. Please note that teas-ietf-slicing-overview does not push for any solution but tries to help navigating in this area. This is not trivial, especially for other SDOs.

> > (3) Please find some very minor nits:
> 
> Nits very welcome and fixed.
> 
> Best,
> Adrian

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.