Skip to main content

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 revision 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
Authors Qin Wu , Stephane Litkowski , Luis Tomotaki , Kenichi Ogaki
I-D 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 M. 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
Request Last Call review on draft-wu-l3sm-rfc8049bis by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 11)
Result Ready w/issues
Completed 2017-10-25
review-wu-l3sm-rfc8049bis-07-genart-lc-arkko-2017-10-25-00
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/