Last Call Review of draft-ietf-kitten-rfc5653bis-05
review-ietf-kitten-rfc5653bis-05-opsdir-lc-clarke-2017-09-05-00

Request Review of draft-ietf-kitten-rfc5653bis
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-09-11
Requested 2017-08-28
Other Reviews Genart Last Call review of -05 by Joel Halpern (diff)
Secdir Last Call review of -05 by Tim Polk (diff)
Genart Telechat review of -06 by Joel Halpern (diff)
Review State Completed
Reviewer Joe Clarke
Review review-ietf-kitten-rfc5653bis-05-opsdir-lc-clarke-2017-09-05
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/lW-SDe9FYIy0iq1bFepJe9xahUs
Reviewed rev. 05 (document currently at 07)
Review result Ready
Draft last updated 2017-09-05
Review completed: 2017-09-05

Review
review-ietf-kitten-rfc5653bis-05-opsdir-lc-clarke-2017-09-05

I have been asked to do an LC review of draft-ietf-kitten-rfc5653bis on behalf of the ops directorate (OPS-DIR).

This draft is an update to the Java bindings for the Generic Security Service API Version 2.

Overall, this document is READY.  It clearly articulates the reason for the modifications in the Appendix, and the changes feel straight-forward and make sense in light of the C API capabilities.

My one concern is the compatibility of this change relative to the previous RFC5653 bindings.  That is, the previous GSSException does not have a getOutputToken method.  The sample application in the draft (section 7) calls this new method (and I like the same covers the relevant change in this doc).  But what happens if my Java library is the older 5653 version?  A NoSuchMethodError will be thrown, which is not ideal.

If there is a set of static properties one can check to see if they have the supported version of the library (and thus the GSSException.getOutputToken() method exists), then the example should use those, and that process should be called out in the text.  In lieu of that, introspection could be used to determine if the new method exists in the current library before it is used.  

This is immediately a concern with any API change, but since the appendix mentions this is a compatible change, I wanted to raise the point.