Skip to main content

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 Snapshot
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