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 revision | 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 E. Carpenter , Bing Liu | |
I-D last updated | 2017-05-22 | |
Completed reviews |
Intdir Early review of -09
by Charles E. 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 M. 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 M. Halpern (diff) Artart Telechat review of -11 by Martin Thomson (diff) Genart Telechat review of -12 by Joel M. Halpern (diff) |
|
Assignment | Reviewer | Joel Jaeggli |
State | Completed | |
Review |
review-ietf-anima-grasp-12-opsdir-lc-jaeggli-2017-05-22
|
|
Reviewed revision | 12 (document currently at 15) | |
Result | Has issues | |
Completed | 2017-05-22 |
review-ietf-anima-grasp-12-opsdir-lc-jaeggli-2017-05-22-00
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