Last Call Review of draft-ietf-teas-actn-framework-13

Request Review of draft-ietf-teas-actn-framework
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-04-30
Requested 2018-04-16
Other Reviews Rtgdir Last Call review of -11 by Bruno Decraene (diff)
Secdir Last Call review of -13 by Catherine Meadows (diff)
Opsdir Last Call review of -13 by Scott Bradner (diff)
Review State Completed
Reviewer Peter Yee
Review review-ietf-teas-actn-framework-13-genart-lc-yee-2018-05-01
Posted at
Reviewed rev. 13 (document currently at 14)
Review result Ready with Issues
Draft last updated 2018-05-01
Review completed: 2018-05-01


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


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: 


Expand acronyms on initial use, particularly if the are not marked as common in the RFC Editor's list:

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.


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