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

Weijun Wang <weijun.wang@oracle.com> Wed, 03 January 2018 03:49 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 59F03127867; Tue, 2 Jan 2018 19:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 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, URIBL_BLOCKED=0.001] 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 YQAMcRaLtVId; Tue, 2 Jan 2018 19:49:00 -0800 (PST)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 93B11120454; Tue, 2 Jan 2018 19:49:00 -0800 (PST)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id w033kxvh030114; Wed, 3 Jan 2018 03:48:57 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=uzCsvAlVodnOywdShEsOVKz1OZI/fqpttUH1d3gk3O4=; b=W/kgbtmOmQ81UfGJ44ikuD8DMw8DkAiaQVRgECPym8jUH5Kn51wC4ZCpoNgChs+qHEXN h1B3pEFvTeKbCFcPbmxzgpmMK42B/7WK0rq6bqG+MaE5GT/TMG2qNOEOQnI6SXZuqtLt kVMVYLC6w8QluF8Az9XIF+0jglb+gIOJY98YYsDNeLWxVQyeMb5esIj453zvneR8YXtZ kcTJT8gnFpw2vaIe0k1GULLBHF3/9btlD6fRELmUIhqoS9gA2sI1zGc22B5t0+cfDlyj xDSUnz88T07RlaS2W6hbT5vi2nfEA8bo7hbfwwtERQpH04lCPCS8ii3QqVTICr/JEU5J oQ==
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2f8pw0r2j7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 03 Jan 2018 03:48:56 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w033msh1026577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 3 Jan 2018 03:48:55 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w033mrVd028355; Wed, 3 Jan 2018 03:48:53 GMT
Received: from [192.168.1.101] (/123.122.152.196) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Jan 2018 19:48:52 -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: <20180103030817.GH50827@kduck.kaduk.org>
Date: Wed, 03 Jan 2018 11:48:47 +0800
Cc: gen-art@ietf.org, kitten <kitten@ietf.org>, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C47701B8-2504-490B-BE38-ED35A1D2C1A2@oracle.com>
References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org>
To: Benjamin Kaduk <kaduk@mit.edu>, "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8762 signatures=668650
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801030049
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/zikeDUDszp5c7XkoAPMO9weYLIA>
Subject: Re: [Gen-art] 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: Wed, 03 Jan 2018 03:49:02 -0000

Thanks for the suggestion. I'll go through the doc and post another version.

--Weijun

> On Jan 3, 2018, at 11:08 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> I am inclined to agree that it is better to change the right ones to
> upper case -- we really don't have a good reason to still be
> producing documents with this type of ambiguity anymore.
> 
> Once that is done we can decide whether the change is
> substantial enough to require re-running the last call.
> 
> -Ben
> 
> On Tue, Jan 02, 2018 at 09:50:19PM -0500, Joel M. Halpern wrote:
>> Personal opinion:
>> Given that to my reading "must" is used on the document in both the RFC 
>> 2119 sense and in a conventional English language sense, it would be 
>> worth clarifying the intention.  As such, I think it would be better to 
>> use the 8174 reference and go through changing the right ones to upper case.
>> 
>> Yours,
>> Joel
>> 
>> On 1/2/18 9:40 PM, Weijun Wang wrote:
>>> Hi Joel and Ben
>>> 
>>> Author here.
>>> 
>>> I think I've removed the section because in fact none of the keywords appears as capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE usage of the key words have the defined special meanings".
>>> 
>>> I assume I'll need to go through the document and make some UPPERCASE and some not, depending on the actual meanings.
>>> 
>>> Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all "must" and "required" in lowercase?
>>> 
>>> Thanks
>>> Weijun
>>> 
>>> 
>>>> On Jan 3, 2018, at 9:49 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>>> 
>>>> Thanks Ben.  That would be good.
>>>> Yours,
>>>> Joel
>>>> 
>>>> On 1/2/18 8:38 PM, Benjamin Kaduk wrote:
>>>>> Hi Joel,
>>>>> On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote:
>>>>>> Reviewer: Joel Halpern
>>>>>> Review result: Ready with Issues
>>>>>> 
>>>>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>>>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>>>>> by the IESG for the IETF Chair. Please wait for direction from your
>>>>>> document shepherd or AD before posting a new version of the draft.
>>>>>> 
>>>>>> For more information, please see the FAQ at
>>>>>> 
>>>>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>>>> 
>>>>>> Document: draft-ietf-kitten-rfc5653bis-06
>>>>>> Reviewer: Joel Halpern
>>>>>> Review Date: 2018-01-02
>>>>>> IETF LC End Date: 2017-09-11
>>>>>> IESG Telechat date: 2018-01-25
>>>>>> 
>>>>>> Summary: This document is ready for publication as a Proposed Standard RFC
>>>>>> 
>>>>>> Major issues: None
>>>>>> 
>>>>>> Minor issues:
>>>>>>     Although ID-Nits does not complain about it, I can find no reference to
>>>>>>     RFCs 2119 or 8174.  Some of the uses of "must" int he document are along
>>>>>>     the lines of "inherently follows", which is not normative language.  But
>>>>>>     other uses are clearly normative in structure.   It is unclear why the
>>>>>>     reference to RFC 2119 was removed as part of this update.
>>>>> Thanks for the review -- I'm a bit surprised that id-nits does not
>>>>> complain about the omission.
>>>>> I do not know why the -00 dropped that clause, but it does seem like
>>>>> the current normal text citing 8174 should be added before
>>>>> publication.
>>>>> -Ben
>>> 
>>>