Last Call Review of draft-wu-l3sm-rfc8049bis-07
review-wu-l3sm-rfc8049bis-07-genart-lc-arkko-2017-10-25-00

Request Review of draft-wu-l3sm-rfc8049bis
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-10-11
Requested 2017-09-13
Other Reviews Rtgdir Last Call review of -07 by Lou Berger (diff)
Opsdir Last Call review of -05 by Carlos Martinez (diff)
Secdir Last Call review of -05 by Rifaat Shekh-Yusef (diff)
Secdir Telechat review of -09 by Rifaat Shekh-Yusef (diff)
Review State Completed
Reviewer Jari Arkko
Review review-wu-l3sm-rfc8049bis-07-genart-lc-arkko-2017-10-25
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/f82N-hEimA0qeIGQjhd_WZ0uoNQ
Reviewed rev. 07 (document currently at 11)
Review result Ready with Issues
Draft last updated 2017-10-25
Review completed: 2017-10-25

Review
review-wu-l3sm-rfc8049bis-07-genart-lc-arkko-2017-10-25

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-wu-l3sm-rfc8049bis-??
Reviewer: Jari Arkko
Review Date: 2017-10-25
IETF LC End Date: 2017-10-11
IESG Telechat date: 2017-10-26

Summary: I'm not an expert on YANG *at all*. And not an expert on the topic in question either. And I had far too little time to spend on this long document. But as far as the textual content of the document goes, it seems reasonable. I have a difficulty in assessing how complete and implementable this model is however. Are there implementations?

I did enjoy the classification of Internet connectivity as a special case of cloud service :-) You may be onto something.

I did observe a couple of question marks or issues that probably deserve some thought or small revisions.

Major issues: -

Minor issues:

I'm not sure I fully understand the need for "SP MUST honour <requirement>" language in the document. Are there parts of the described model that they SP is *not* required to honour? Other than the explicit strict true/false settings? And in any case, sizeable networks are likely to have issues that might require negotiation/human involvement.

I don't understand how 6.9.1 can say there is no authentication support but then 6.9.2 (encryption) talks about authentication keys. I'd suggest some rethinking or at least clarification might be needed here.

In the security considerations, I would note that if these models are used not merely for creation of networks, but also their modification, the consequences of inadvertent or malicious modifications can severe and network wide. Perhaps that could be discussed.

Nits/editorial comments: 

Section 6.12.2. s/fragmented/fragment it/