Last Call Review of draft-ietf-anima-grasp-12
review-ietf-anima-grasp-12-opsdir-lc-jaeggli-2017-05-22-00
| Request | Review of | draft-ietf-anima-grasp |
|---|---|---|
| Requested rev. | no specific revision (document currently at 15) | |
| Type | Last Call Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2017-03-02 | |
| Requested | 2017-02-16 | |
| Authors | Carsten Bormann, Brian Carpenter, Bing Liu | |
| Draft last updated | 2017-05-22 | |
| Completed reviews |
Intdir Early review of -09 by Charles Perkins
(diff)
Opsdir Last Call review of -12 by Joel Jaeggli (diff) Secdir Last Call review of -09 by Barry Leiba (diff) Genart Last Call review of -09 by Joel Halpern (diff) Tsvart Telechat review of -11 by Martin Stiemerling (diff) Secdir Telechat review of -11 by Barry Leiba (diff) Genart Telechat review of -11 by Joel Halpern (diff) Artart Telechat review of -11 by Martin Thomson (diff) Genart Telechat review of -12 by Joel Halpern (diff) |
|
| Assignment | Reviewer | Joel Jaeggli |
| State | Completed | |
| Review | review-ietf-anima-grasp-12-opsdir-lc-jaeggli-2017-05-22 | |
| Reviewed rev. | 12 (document currently at 15) | |
| Review result | Has Issues | |
| Review completed: | 2017-05-22 |
Review
review-ietf-anima-grasp-12-opsdir-lc-jaeggli-2017-05-22
I was asked to perform a sublimental opsdir review of draft-ietf-anima-grasp https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ My conclusion after reading is that the document is ready with some fairly serious caveats. caveat 1 - Transport is fiddly. The document allows for the use of UDP but is probably insufficiently specified to allow for reliable and inter-operable operation. Use of tcp and therefore some assumption about reliable transport go a long way towards ameliorating the concern. caveat 2 - multicast / flooding is messy. The document is proscriptive with respect to the sorts of information which can safely be carried via multicast. but the desire to statelessly flood messages and the tendancy for leakage probably encourage unsafe usage when the unicast (and secured) transport is already required. multicast should probably be limited exclusively to discovery and initial bootstrap. I don't know if these considerations are important enough to be blocking. considering the relative maturity of demonstrated implementations, I would expect that developer's implementations would be confined to what they need. marking it experimental might encourage a future specification to be tighten up to what is in fact used. joel