Re: [Gen-art] [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06

Weijun Wang <weijun.wang@oracle.com> Thu, 08 February 2018 03:36 UTC

Return-Path: <weijun.wang@oracle.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFF412D77D; Wed, 7 Feb 2018 19:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.031
X-Spam-Level:
X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 mdLJJh0U56En; Wed, 7 Feb 2018 19:36:35 -0800 (PST)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49FC11200F1; Wed, 7 Feb 2018 19:36:35 -0800 (PST)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w183NSuX154575; Thu, 8 Feb 2018 03:36:31 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=+8mtUvpdXCIhfdMb9xWHeL+jMcew5KUZKQtrdB7smVk=; b=AIfBLSkQEoEl7Njq9Dn/JN+enVgVipUfuY3Eg6QNzjnKNmI4LTZ9Ih1oAMYcx3nuWMRu a/wC+eP1o7gmc5BFASiP6vDmeo6ckU+tgtJE0guwWgyFuw/YpaeeYHU/6dhCjfxdhwj6 0nDHlfRtHrWX6u2+CDWrIywYT7A8xvxdxzLQ616t5bsaAjlDcpdLVXS8CCh2BdZhcBOJ 2hOV7AQKKCNV8jXLTNLGlJDdozQMdTZkFR3LdOXiWYHZdFM9idJ3hQD6dN82sYT73sMs YyLv0RMu3M7HFupJIqFlPCzZcAcdb8m7coyph7i7YY6281T9K387i4Gbc+C58uIsJasI hQ==
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2g0ekpr0sw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 08 Feb 2018 03:36:31 +0000
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w183aUY8027256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 8 Feb 2018 03:36:30 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w183aTPv024855; Thu, 8 Feb 2018 03:36:29 GMT
Received: from [192.168.1.105] (/114.250.155.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Feb 2018 19:36:29 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Weijun Wang <weijun.wang@oracle.com>
In-Reply-To: <20180207225756.GC12363@mit.edu>
Date: Thu, 08 Feb 2018 11:36:23 +0800
Cc: Greg Hudson <ghudson@mit.edu>, draft-ietf-kitten-rfc5653bis.all@ietf.org, kitten <kitten@ietf.org>, gen-art <gen-art@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Alissa Cooper <alissa@cooperw.in>
Content-Transfer-Encoding: 7bit
Message-Id: <933B4F63-BBDD-450D-A17A-3972F53B3EE4@oracle.com>
References: <20180103030817.GH50827@kduck.kaduk.org> <C47701B8-2504-490B-BE38-ED35A1D2C1A2@oracle.com> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <D6DB69A6-5768-4536-89AA-40E0A905DF95@oracle.com> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> <20180207173534.GX12363@mit.edu> <20180207213248.GB12363@mit.edu> <0c34b6ba-cd35-aca5-e9d1-e15e0812413d@mit.edu> <20180207225756.GC12363@mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.5.20)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8798 signatures=668663
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=8 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=904 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802080022
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/DGEO53TJprFHHl3ou1fDeJvRBSw>
Subject: Re: [Gen-art] [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2018 03:36:37 -0000

Thanks a lot. I finally make 3 s/not/NOT/ and 2 s/MAY/may/.

@@ -410,7 +410,7 @@
       of sequence.
 
       Anonymous Authentication: The establishment of the security
-      context SHOULD not reveal the initiator's identity to the context
+      context SHOULD NOT reveal the initiator's identity to the context
       acceptor.
 
    Some mechanisms may not support all OPTIONAL services, and some
@@ -2665,7 +2665,7 @@
    ability may depend on the availability of system resources at the
    time that wrap is called.  However, if the implementation itself
    imposes an upper limit on the length of messages that may be
-   processed by wrap, the implementation SHOULD not return a value that
+   processed by wrap, the implementation SHOULD NOT return a value that
    is greater than this length.
 
    Parameters:
@@ -2855,7 +2855,7 @@
    The implementation MAY constrain the set of processes by which the
    inter-process token may be imported, either as a function of local
    security policy, or as a result of implementation decisions.  For
-   example, some implementations MAY constrain contexts to be passed
+   example, some implementations may constrain contexts to be passed
    only between processes that run under the same account, or which are
    part of the same process group.
 
@@ -3046,7 +3046,7 @@
    public boolean isProtReady()
 
    Returns "true" if the per-message operations can be applied over the
-   context.  Some mechanisms MAY allow the usage of per-message
+   context.  Some mechanisms may allow the usage of per-message
    operations before the context is fully established.  This will also
    indicate that the get methods will return actual context state
    characteristics instead of the desired ones.
@@ -3713,7 +3713,7 @@
 
    outputToken         The output token that SHOULD be sent to the peer.
                        Can be null if no such token is available.  It
-                       MUST not be an empty array.  When provided, the
+                       MUST NOT be an empty array.  When provided, the
                        array will be cloned to protect against
                        subsequent modifications.

Thanks
Weijun

> On Feb 8, 2018, at 6:57 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> On Wed, Feb 07, 2018 at 05:43:58PM -0500, Greg Hudson wrote:
>> On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should
> [line 2519]
>> --> SHOULD, since elsewhere we use SHOULD
>>> for sending the error token to the peer.
>> 
>> No opinion.  You could make a case for "that should be sent" being
>> either descriptive on the token or prescriptive on the application.
> 
> Re-reading, I agree with you and retract the suggestion.
> 
>>> Line 2561, I could go either way on "may" vs. "MAY" -- the argument
>>> for the former would be that it's just stating an attribute of the
>>> operation, and this text is describing something specified elsewhere
>>> and not introducing any restrictions or giving guidance on it.
>>> Similarly for acceptSecContext on line 2597.
>> 
>> I think that's a MAY.  It seems prescriptive on the method implementation.
> 
> Okay.
> 
>>> Line 2668, SHOULD not --> SHOULD NOT
>> 
>> Agree.
>> 
>>> Line 2858, MAY --> may, since this is just describing what some
>>> implementations could be doing and not exactly granting permission
>>> for it.
>> 
>> Sure, and it's an example.
>> 
>>> I guess for consistency I should say the same thing about line 3049.
>> 
>> I guess "may" here, but no strong opinion.
>> 
>>> Line 3716, MUST not --> MUST NOT
>> 
>> Agree.
> 
> Thanks for double-checking my work.
> 
> -Ben