Re: comments on java bindings update, draft-ietf-kitten-rfc2853bis-02

Jeffrey Altman <jaltman@secure-endpoints.com> Tue, 14 November 2006 16:08 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0q3-0003Wk-EU; Tue, 14 Nov 2006 11:08:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0q2-0003WW-5U for kitten@ietf.org; Tue, 14 Nov 2006 11:08:42 -0500
Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0pz-0001Y8-AX for kitten@ietf.org; Tue, 14 Nov 2006 11:08:42 -0500
Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kAEG8YgO022047 for <kitten@ietf.org>; Tue, 14 Nov 2006 11:08:36 -0500 (EST)
Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000034847.msg for <kitten@ietf.org>; Tue, 14 Nov 2006 11:09:11 -0500
Message-ID: <4559EA2B.5000201@secure-endpoints.com>
Date: Tue, 14 Nov 2006 11:09:15 -0500
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Organization: Secure Endpoints Inc.
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Seema.Malkani@Sun.COM
References: <E6F31331-D44A-4599-AC98-2AD748A81B66@mit.edu> <4553A4A2.3060809@Sun.COM>
In-Reply-To: <4553A4A2.3060809@Sun.COM>
X-Enigmail-Version: 0.94.0.0
X-Authenticated-Sender: jaltman@secure-endpoints.com
X-Spam-Processed: www.secure-endpoints.com, Tue, 14 Nov 2006 11:09:11 -0500 (not processed: message from valid local sender)
X-Return-Path: jaltman@secure-endpoints.com
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kitten@ietf.org
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f
Cc: kitten@ietf.org, Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: comments on java bindings update, draft-ietf-kitten-rfc2853bis-02
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jaltman@secure-endpoints.com
List-Id: Common Authentication Technologies - Next Generation <kitten.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kitten>
List-Post: <mailto:kitten@lists.ietf.org>
List-Help: <mailto:kitten-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1790195014=="
Errors-To: kitten-bounces@lists.ietf.org

Speaking as an individual, not as Chair.

Seema Malkani wrote:
> Thanks for the review, Ken.
> 
> Ken Raeburn wrote On 11/07/06 18:56,:
> 
>> Jeff was complaining because not enough people had reviewed the java 
>> bindings, so I took a look.  Not that I'm any great expert on Java, 
>> but I do okay with English and sometimes even with GSSAPI...
>>
>> The abstract says in part:
>>
>>       This document
>>     updates the Java bindings for the GSS-API that are specified in
>>     "Generic Security Service API version 2 : Java Bindings" (RFC2853).
>>     This document obsoletes RFC2853 by making specific and incremental
>>     clarifications and corrections to it in response to 
>> identification of
>>     transcription errors and implementation experience.  The note-worthy
>>     changes are in sections 4.12.1, 6.2.2, 6.3.2, and 6.8.1 of RFC2853,
>>     which are replaced by the sections 5.12.1, 7.2.2, 7.3.2, and 
>> 7.8.1 of
>>     this document, where numerical constants were either added or
>>     modified.
>>
>> But aside from this, I didn't see a detailed description of just 
>> what's changed from the previous version.  (I didn't go back and 
>> check the email archives though.)  A non-normative section listing 
>> the changes from RFC 2853 would've been helpful.
> 
> The Abstract has a summary of changes, listing the specific section
> updates. Would a list of changes in an Appendix section at the end of
> the draft be helpful ?

The Abstract is just that "an abstract".  It summarizes the contents
of the document so that readers do not have to examine all 100+ pages
to determine if the document is meaningful to them.

In this particular case, since this document replaces the previous
one and does not update it, I think the abstract needs to be corrected.
This document obsoletes RFC2853.  I agree with Ken that the list of
changes should be specified in an Appendix.  The list of changes should
be sufficiently complete so that someone who implemented RFC2853 can
determine whether or not their implementation is still compliant.

>> So I poked at the two versions with Emacs a bit, stripping out page 
>> headers and footers and line breaks and comparing what was left.  I 
>> think my list covers everything changed, and I've got comments on 
>> some of the changes:
>>
>> * minor grammatical fixes, basic text changes in the intro relating 
>> to this being an update
>>
>> * changes to various number assignments, new status codes added
> 
> The GSS status code update is the one of the significant update to RFC
> 2853. The GSS error code values use for GSS exceptions were incorrect in
> the original RFC 2853.

In the Appendix of changes should be a table that indicates what the
wrong values were and what the correct values are.

>> * added labels "Figure 3" through "Figure 9" to various tables, 
>> though the labels aren't always on the same page as the table being 
>> labeled (e.g., "Figure 3" at the top of page 32, describing the table 
>> that's on page 31); where are Figures 1 and 2?  Can the labels just 
>> go away?
> 
> RFC 2853 was written in text format, hence labeling was easier to add.
> And now RFC 2853 Update has been written in XML format, the labeling
> comes from the standard xml tags.

You might want to check on the XML2RFC list to see if there is a better
way of handling table labels.

>> * java syntax tweaks (array parameters, missing return types)
>>
>> * specify values for INITIATE_AND_ACCEPT and friends in a bunch of 
>> places (isn't one enough?), where they weren't specified at all in 
>> rfc2853
> 
> RFC 2853 defined the Credential usage Static constants in section 6.3.2,
> but missed defining the usage values.
> 
> This draft defines the Credential usage values in section 7.3.2

This should be explicitly stated in the Appendix.

>> * status code values being specified in a couple of places now 
>> (5.12.1, 7.8.1); I didn't check for consistency
> 
> GSS status code values in RFC 2853 were not consistent. The draft now
> defines in GSS error code values that are consistent.

>> * change NT_HOSTBASED_SERVICE OID value from the deprecated value to 
>> the current one (as described in the C bindings in RFC 2744); the new 
>> version has a typo ("Unites States", which is also present in RFC 2744)
> 
> This needs to be fixed, I'll make the update.
> 
> { iso(1) member-body(2) United States(840) mit(113554) infosys(1)
> gssapi(2) generic(1) service_name(4) }
> 
>>
>> * change text describing lifetime constants from "must be set to..." 
>> to "value of constant is..."
> 
> This update defines the recommended value.

Is this value a SHOULD or a MUST?

Is this a change from RFC2853?

>> * corrected name of References section
>>
>> * updated IPR & Copyright, new authors' addresses
>>
>> * inserted the usual "conventions used in this document" section, 
>> before the introduction (resulting in a renumbering of sections 
>> through the whole document), even though the key words described 
>> there are not actually used in the document; I haven't checked the 
>> rules, but I would hope we can omit it in that case
> 
> The keywords defined in the Normative References are used in the draft.
> Can you clarify what keyword are you referring to ?

I suspect Ken is referring to:

MUST, SHOULD, SHOULD NOT, MUST NOT, ....

>> RFC 2744 inconsistencies notwithstanding, I think this spec should 
>> use consistent style for specifying OID values.  Is it "iso(1)" or "1
>> (iso)"?
> 
> RFC 4120, RFC 2744, RFC2743 all define iso(1). This draft follows the
> same. Is this not the correct style ?

Ken's point is that you should be consistent within this document.  A
quick scan shows both styles:

 { iso(1) member-body(2) United States(840) mit(113554)
   infosys(1) gssapi(2) generic(1) machine_uid_name(2) }

 { 1(iso), 3(org), 6(dod), 1(internet), 5(security),
   6(nametypes), 3(gss-anonymous-name)

I prefer the first.  I agree with Ken, please make them consistent.

Jeffrey Altman
_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten