Re: [Teas] [Last-Call] Intdir telechat review of draft-ietf-teas-ietf-network-slices-21

[Dirk Hugo <[e-mail]>]

Hi all,thanks for the replies and the proposed clarifications/solutions are
all fine for me - as mentioned, I only detected very minor issues.
Best regards Dirk

On Mon, Jul 24, 2023, 4:07 PM Adrian Farrel <[e-mail]> wrote:

> Hey Dirk,
>
> Many thanks for this careful review and apologies for the delay in replying
> (I am currently away from home at a small networking conference).
>
> Tl;dr  Nearly completely "Yes"
>
> Individual response in line.
>
> Cheers,
> Adrian
>
> > The following are other (minor) issues I found with this document that
> SHOULD
> > be corrected before publication:
> >
> > Since on p.3 scope is limited to network technologies described and
> > standardized by the IETF, I would omit on p.4 mentioning 'optical' and
> mayde
> > replace by L3VPN or other IETF network technology.
>
> We talked about this on a separate thread, and I am not going to omit
> 'optical'. But I will add some words to clarify that we are talking about
> an
> IETF-specified data plane and/or management/control plane.
>
> > The following are very minor issues (typos, misspelling, minor text
> > improvements) with the document:
> >
> > p.3: (e.g. eMBB => (e.g., eMBB
> > a customer to describe their => customers to describe their
>
> Ack
>
> > p.5: resources (e.g. =>resources (e.g.,
> > of data, control and =>  of data, control, and
> > level of control of, e.g., to customize => level of control to, e.g.,
> customize
> > [?] OR: level of control of means, e.g., to customize
>
> Ack
>
> > p.6: maybe a physical => may be a physical
>
> Ack
>
> > p.15: Maximum Permissible Packet Loss Rate:  The ratio => Maximum
> Permissible
> > Packet Loss Ratio:  The ratio
>
> Nice! And found another of these.
>
> > p.16:  (e.g. diversity, =>  (e.g., diversity,
>
> Ack
>
> > p.23: issues of abstraction in a TE network => issues of abstraction in a
> > Traffic Engineering (TE) network
>
> Ow, wow! Yes.
>
> > This API communicates => This Interface can be seen as Application
> Programming
> > Interface (API) communicating
>
> API is starred at
> https://www.rfc-editor.org/materials/abbrev.expansion.txt
> and I suspect more than a few readers will be familiar with the term.
>
> > p.25: provisioning, operating and => provisioning, operating, and
>
> Ack
>
> > p.34: underpin a IETF Network => underpin an IETF Network
>
> Oops.
>
> > p.35: instantiate such an IETF Network Service Slice. => instantiate such
> an
> > IETF Network Slice. [expression of 'IETF Network Service Slice' is not
> defined
> > nor used anywhere else in the document]
>
> Yeah, could catch. "IETF Network Slice Service"
>
> > p.37: IETF Network Slices Service => IETF Network Slice Services
>
> Ack
>
> > p.38: be mitigated by reduding the access => be mitigated by reducing the
> > possibility of access [?]
>
> I think this one stands.
>
> > p.39: importance that the system use the privacy protection mechanism =>
> > importance that the system uses the
> > privacy protection mechanism
>
> A grumpy Ack here.
>
> > p.47: In many case, => In many cases,
>
> Ack
>
> > p.49: is no different to => is not different to OR: does not differ from
>
> More grumpy conversion to common usage ;-)
>
> > p.51: End-to- End Connectivity => End-to-End Connectivity
>
> Ack
>
> > p.52: with Inter- connected Networks => with Inter-connected Networks OR:
> with
> > Interconnected Networks [consistent use within the document]
>
> Ack
>
> > Also consistent use of US or UK English spelling - e.g. characterise vs.
> > characterize should be achieved IMO.
>
> Global change
> "enterprise" --> "enterprize" and "otherwise" --> "otherwize"
> Back out global change, and do the work properly.
>
>
>
>