Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

[Adrian Farrel <[e-mail]>]

Hi Xiaobing,

> Some typo or comments for your consideration,

Many thanks. In line…

> 1. Page 10, the first line: be determined [by] the customer...

Ack

> 2. Page 12, in 4.2:  the 'multipoint-to-point' is duplicate.      
                The IETF NSE[s] are conceptual points of connection ...

Yes, to both.

> 3. Page 12,  it says,
>
> 'An NSE should be identified by a unique ID in the context of an  IETF Network
>  Slice customer.'
> 'A combination of NSE unique ID and NSE attributes defines an NSE in the
>  context of the IETF Network Slice Controller (NSC).'
>
> The unique ID of NSE is in the context (or name space) of IETF Network Slice
> customer. The context/name space of IETF Network slice customer may be
> different from the context of IETF network slice controller, considering, for
> example, difference customers could use different the same unique ID in
> their own customer contexts. It may need to consider the difference between
> the customer context and NSC context in order to keep the ID unique.

Right. I think the NSC is going to be aware of the customer ID/name, so that in the provider's context the NSE is identified by {customer,  NSE ID}.

I'm pretty sure the point here is that the NSE identifiers form a set across all of the slices that a single customer has and the NSE IDs are, therefore, unique within the customer scope not within the scope of a slice.

I don't see a typo to change here.

> 4. Page 20, 'IEFT' typo

Yes

> 5. Page 20,  'are mapped to the underlay IETF Network Slice Endpoints
>   (NEPs)'.    The abbreviation could be NSEs while not NEPs.

Oops 😊
Actually, this should be "EP" as in the diagram. A little additional tidying of the text is needed.

> 6. Page 24, security consideration, 'as some aspects of security may be expressed
>   in SLOs.'    
>   According to 4.1.2.1, security is expressed in SLE, and here, the SLOs could be SLEs.

Oh, well found!

Best,
Adrian