Jari, thanks for your review. I have entered a No Objection ballot. Alissa
> On Oct 25, 2017, at 4:53 PM, Jari Arkko <[email protected]> wrote: > > Reviewer: Jari Arkko > 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-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/ > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
