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> Fri, 06 February 2015 00:51 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 859F21A0027 for <kitten@ietfa.amsl.com>; Thu, 5 Feb 2015 16:51:38 -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 WQGxwlxGNFES for <kitten@ietfa.amsl.com>; Thu, 5 Feb 2015 16:51:35 -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 69E8C1A0029 for <kitten@ietf.org>; Thu, 5 Feb 2015 16:51:35 -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 t160pY68003344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Feb 2015 00:51:34 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t160pX9d029088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Feb 2015 00:51:34 GMT
Received: from ubhmt102.oracle.com (ubhmt102.oracle.com [156.151.24.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t160pX9N029085; Fri, 6 Feb 2015 00:51:33 GMT
Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Feb 2015 16:51:33 -0800
Message-ID: <54D4100E.7070200@oracle.com>
Date: Fri, 06 Feb 2015 08:51:26 +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> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu>
In-Reply-To: <54D40D6A.7010704@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/-ALdj5lwUW5s_U6oro0UpZyeXU0>
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: Fri, 06 Feb 2015 00:51:38 -0000


On 2/6/2015 8:40, Greg Hudson wrote:
> On 02/05/2015 07:04 PM, Weijun Wang wrote:
>> One problem is that if the app "have already written extra code to
>> generate that token and send it", now it will send it twice.
>
> How would an app generate its own GSSAPI error token?  Surely it would
> have to have intimate knowledge of the mech in order to do so.

I don't know if there exists an app doing that. Still possible. Maybe I 
am just looking for reasons to persuade myself. :-)

>
>> Stream methods are not used by many. So most people would have to
>> rewrite their apps to make use of this feature.
>
> Fair enough.
>
> If, considering all of the arguments given thus far, you still feel that
> it's better for the stream methods to be consistent with the byte
> methods, I don't have any strong objection to keeping it the way it is.

That's still my position. I just don't want to introduce a behavior change.

Thanks for all the advices. I'll prepare a -02 draft including other 
changes you suggested.

--Weijun