[Teas] Genart last call review of draft-ietf-teas-actn-framework-13

[Peter Yee <[e-mail]>]

Reviewer: Peter Yee
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-teas-actn-framework-13
Reviewer: Peter Yee
Review Date: 2018-05-01
IETF LC End Date: 2018-04-30
IESG Telechat date: 2018-05-24

Summary: This draft is a framework for taking an abstract look at how traffic
engineered networks can be provisioned and controlled.  There are some issues
with looseness in terms that make it more difficult to understand than it needs
to be. [Ready with issues]

Major issues: None

Minor issues:

Page 12, Figure 2: Figure 1 and the preceding text say that it’s
Customer->Service Provider->Network Provider, but then here you have a business
boundary between a customer and a network provider.  I get that the model can
be recursive, but I find it confusing that you’re discussing an architecture
that throws out the part of the terminology of the model that was just
presented two pages previously.  This is symptomatic of a problem I have with
the looseness of the language in the document in which terms like (point, node)
and (service provider, network provider, operator) are used interchangeably,
even in contravention of how they are defined in the document.  This makes
sections 2 and 3 somewhat confusing.

Page 12, Section 3.1, 1st sentence: Wait, 2.2.2 says that VNS are delivered by
the service providers, not network providers.  Yes, SPs can also be customers
of infrastructure-only network providers (2.2.2, para 2), but this muddles the
picture.  If CNCs are Service Provider devices (functions), then I withdraw the
comment, but the naming (CNC) doesn't make it obvious that these are part of an
SP.  The model given in Figure 1 and Section 2 strikes again.

Nits/editorial comments:

General:

Expand acronyms on initial use, particularly if the are not marked as common in
the RFC Editor's list:
https://www.rfc-editor.org/materials/abbrev.expansion.txt.

Use a comma after each "e.g." (only a couple were missing).

Change "multi domain" to "multidomain" (or "multi-domain").  Make a similar
change for "inter domain".

Separate "Gbps" from the preceding number throughout the document.

Specific:

Page 4, 1st full paragraph, last sentence: make "function" plural.

Page 5, 2nd bullet item: append a comma after "application".

Page 5, Section 2.1, 1st sentence: append a blank line after this sentence to
separate it from the following bullet item.

Page 6, 1st partial paragraph, 1st partial sentence: make the last use of
"network" plural.

Page 6, 1st partial paragraphk, 1st full sentence: change "Network" to
"network".

Page 6, 3rd bullet item: isn't this redundant since the 2nd bullet item
essential defines it as well, especially with the reference to RFC 7926
[section 1.1.9]?

Page 7, 1st bullet item: delete two excess, blank lines above the bullet items.

Page 11, 1st bullet item: this is basically a description of the MDSC.  You
manage to make a forward reference to PNC here.  Why not just drop MDSC in
there as well?

Page 11, last bullet item: change "South Bound" to "Southbound", as used later
in the document.

Page 18, section 5.2.1, 1st sentence: change "information. I.e." to
"information, i.e.".

Page 20, 1st sentence:  It might be reasonable to change "modes" to "types" to
match the usage in the following two bullet items.

Page 20, 1st bullet item: append a comma after "topology" and delete the second
occurrence of "type".

Page 20, 2nd bullet item: append a comma after "topology".

Page 25, Figure 10: explain what the line thicknesses mean.  It's almost
certainly not what was meant in Figure 9.

Page 26, 1st sentence after Table 1: what kind of provider is being discussed
here, network or service?  Does it matter?  Does the separation of such in the
model matter?  (See Minor Issues.)

Page 27, section 6.1, 1st paragraph, 1st sentence: append a comma after "APs".

Page 28, Table 4: It's not really clear to me how AP3 ends up with 40 Gbps
bandwidth.  It seems like you might be reusing assumptions from the previous
example, but you should really set up the multi-homing example more clearly. 
In the previous example, AP2 was in a different domain, so it's not apparent
why it would have 40 Gbps in this example.

Page 33, section 9, 2nd paragraph: append "of whether" after "regardless".