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 | |
| Draft last updated | 2017-10-25 | |
| Completed reviews |
Rtgdir Last Call review of -07 by Lou Berger
(diff)
Opsdir Last Call review of -05 by Carlos MartÃnez (diff) Genart Last Call review of -07 by Jari Arkko (diff) Secdir Last Call review of -05 by Rifaat Shekh-Yusef (diff) Secdir Telechat review of -09 by Rifaat Shekh-Yusef (diff) |
|
| Assignment | Reviewer | Jari Arkko |
| State | Completed | |
| Review | review-wu-l3sm-rfc8049bis-07-genart-lc-arkko-2017-10-25 | |
| Reviewed rev. | 07 (document currently at 11) | |
| Review result | Ready with Issues | |
| 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/