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 <adrian@xxxxxxxxxxxx> 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
