Subject: Opsdir last call review of draft-ietf-kitten-rfc5653bis-05

From: Joe Clarke <[email-masked]>
Date: Tue, 05 Sep 2017 12:00:08 -0700

Reviewer: Joe Clarke
Review result: Ready

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.

---

From: Weijun Wang <[email-masked]>
Date: Wed, 6 Sep 2017 13:42:28 +0800

Hi Joe

When I said it's a compatible change, I meant the behavior is compatible, so either initSecContext or acceptSecContext still throws an exception instead of returning KRB-ERROR in a byte array. I know "compatibility" has lots of different meanings.

If this method is called directly (not via refection) it will only compile with a new JDK. The program will not run with an old JDK because in Java the class file contains a magic number that increases with each version. This happens before you can see a NoSuchMethodError.

If a developer wants an application or library runnable with an old JDK release but also like to benefit from the new method when running with a new release, some kind of reflection (GSSException.class.getMethod) is needed. In this case the developer will certainly be aware that this method might not exist and deal with it carefully.

I feel hesitated to add reflection calls to all examples since that will look quite a mess. How about changing the last paragraph of Section 11 1) to something like:

   New JGSS programs should make use of this new method but it is not mandatory.
   A program that intends to run with both old and new Java releases can use
   reflection to check the availability of this new method and call it accordingly.

Thanks
Max

> 
> On Sep 6, 2017, at 3:00 AM, Joe Clarke <[email-masked]> wrote:
> 
> Reviewer: Joe Clarke
> Review result: Ready
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Joe Clarke <[email-masked]>
Date: Wed, 6 Sep 2017 09:00:55 -0400

> If this method is called directly (not via refection) it will only compile with a new JDK. The program will not run with an old JDK because in Java the class file contains a magic number that incre…

Yes, compile-time will stop you.  But if you distribute an app with
someone else's jar... (I know you know this :-) ).

>    reflection to check the availability of this new method and call it accordingly.

I'm good with this.  A slight change, though:

"A program that intends to run with both old and new GSS Java bindings
can use reflection to check the availability of this new method and call
it accordingly."

You're right that adding reflection to the example would just muddle it.
 In a perfect world, you'd have the latest jar with the an app written
for it.  So the example is good.

But my experience with Java is that you may not get the jar you expect,
and changes like this that are said to be "compatible" can often bite you.

Joe

---

From: Weijun Wang <[email-masked]>
Date: Wed, 6 Sep 2017 22:17:32 +0800

Hi Joe

> On Sep 6, 2017, at 9:00 PM, Joe Clarke <[email-masked]> wrote:
> 

Accepted. You do not mean to remove the existing "New JGSS programs should make use of this new method but it is not mandatory" sentence, right?

Is there anything else I need to touch before posting the -06 version of this ID?

> and changes like this that are said to be "compatible" can often bite you.

Since this is inside Java SE, hopefully the situation is better than a 3rd party API. Of course, with the new modularized structure introduced in JDK 9, people might start making JDK images of their own which contain modules from different releases and different vendors...

Thanks
Max

---

From: Joe Clarke <[email-masked]>
Date: Wed, 6 Sep 2017 10:19:25 -0400

> Accepted. You do not mean to remove the existing "New JGSS programs should make use of this new method but it is not mandatory" sentence, right?

Correct.  I was just changing that last sentence.  I intended you to
keep the quoted sentence you have above.

> Is there anything else I need to touch before posting the -06 version of this ID?

Not from my OPS-DIR review.

> Since this is inside Java SE, hopefully the situation is better than a 3rd party API. Of course, with the new modularized structure introduced in JDK 9, people might start making JDK images of thei…

Yes.  It was really the "compatible" word that piqued my thinking.

Joe