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
Other Reviews Intdir Early review of -09 by Charles Perkins (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)
Review State Completed
Reviewer Joel Jaeggli
Review review-ietf-anima-grasp-12-opsdir-lc-jaeggli-2017-05-22
Posted at https://www.ietf.org/mail-archive/web/ops-dir/current/msg02653.html
Reviewed rev. 12 (document currently at 15)
Review result Has Issues
Draft last updated 2017-05-22
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