Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00

Weijun Wang <weijun.wang@oracle.com> Mon, 02 February 2015 03:03 UTC

Return-Path: <weijun.wang@oracle.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430A1A9244 for <kitten@ietfa.amsl.com>; Sun, 1 Feb 2015 19:03:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zymKDQlhli02 for <kitten@ietfa.amsl.com>; Sun, 1 Feb 2015 19:03:16 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C711A9174 for <kitten@ietf.org>; Sun, 1 Feb 2015 19:03:16 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1233ErU007049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Feb 2015 03:03:15 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1233E8D006464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2015 03:03:14 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t1233DAd020278; Mon, 2 Feb 2015 03:03:13 GMT
Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 01 Feb 2015 19:03:13 -0800
Message-ID: <54CEE8E5.5080701@oracle.com>
Date: Mon, 02 Feb 2015 11:03:01 +0800
From: Weijun Wang <weijun.wang@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>, kitten@ietf.org
References: <alpine.GSO.1.10.1501201753140.23489@multics.mit.edu> <54CE9F5B.9070808@mit.edu>
In-Reply-To: <54CE9F5B.9070808@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/X3VlBXuHYgXucUug8xWM7rNkjt8>
Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 03:03:17 -0000


On 2/2/2015 5:49, Greg Hudson wrote:
> On 01/20/2015 06:02 PM, Benjamin Kaduk wrote:
>> http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00
>
> I reviewed this and did not find any problems with it.
>
>> http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01
>
> My only substantive note is that the InputStream/OutputStream forms of
> initSecContext/acceptSecContext could, perhaps, already write tokens to
> the outStream parameter before throwing an exception, instead of
> communicating them in the exception.  If this issue has already been
> discussed, please ignore this remark.  If not, I suspect it might be
> easier on callers (but perhaps harder on implementations) just to
> require that callers flush or otherwise handle content in the output
> stream after an exception.  I do not have a strong interest in how this
> turns out, though.

The main reason I preferred the current design is to be consistent with 
the byte array forms of the methods, which gives the caller the chance 
to determine whether the error token should be sent or not.

>
> Some text was removed from the copyright notice about containing
> pre-2008 material.  If this was intentional, please ignore this remark.

The whole Copyright Notice section is automatically generated by 
xml2rfc. I thought that paragraph is a standard part of every old RFC 
and the new format should override it. If not, I'll add it back (I'll 
have to figure out where to add it in the XML file).

>
> In several places the draft uses the new text "to inform the reason for
> the error," which is not correct English.  I suggest "to communicate the
> reason for the error."

OK.

>
> The section 5.2 table contains the pre-existing typo "Covert" for
> "Convert".  I noticed because the table was reformatted; it may or may
> not be worth correcting.

I've correct it.

Thanks
Weijun

>
>> http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00
>
> I found a typo: "optionSHOULD" for "option SHOULD."
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>