[secdir] Review of draft-ietf-httpbis-rfc5987bis-04

zhangdacheng <dacheng.zhang@huawei.com> Mon, 20 February 2017 03:12 UTC

Return-Path: <dacheng.zhang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4DE12943A; Sun, 19 Feb 2017 19:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 aG6h3nIqalUZ; Sun, 19 Feb 2017 19:12:40 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650BA1293EE; Sun, 19 Feb 2017 19:12:39 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAX12859; Mon, 20 Feb 2017 03:12:37 +0000 (GMT)
Received: from LHREML710-CAH.china.huawei.com (10.201.108.33) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 20 Feb 2017 03:12:36 +0000
Received: from SZXEMI415-HUB.china.huawei.com (10.86.210.48) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 20 Feb 2017 03:12:35 +0000
Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.216]) by SZXEMI415-HUB.china.huawei.com ([10.86.210.48]) with mapi id 14.03.0235.001; Mon, 20 Feb 2017 11:12:32 +0800
From: zhangdacheng <dacheng.zhang@huawei.com>
To: 'secdir' <secdir@ietf.org>, 'The IESG' <iesg@ietf.org>
Thread-Topic: Review of draft-ietf-httpbis-rfc5987bis-04
Thread-Index: AdKLJTvGJswF18oXQ9qocLPojVvtjA==
Date: Mon, 20 Feb 2017 03:12:31 +0000
Message-ID: <879E76B64CF340468BF5E4DE504C2242C17179@szxemi502-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.167.227]
Content-Type: multipart/alternative; boundary="_000_879E76B64CF340468BF5E4DE504C2242C17179szxemi502mbxchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58AA5EA5.007D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.216, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c4e71fab1af2012a37141d4b6f1b79a7
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/NGLbUbktghspmvNykOuHObrPy-w>
Cc: "draft-ietf-httpbis-rfc5987bis.all@ietf.org" <draft-ietf-httpbis-rfc5987bis.all@ietf.org>
Subject: [secdir] Review of draft-ietf-httpbis-rfc5987bis-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2017 03:12:42 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.


This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC2231, and obsoletes RFC5987.



Compared to RFC 5987, the updates in this document does not introduce any additional security considerations, and the contents in the security considerations section is exactly identical to the counterparts in RFC 5987. So, I agree this document is ready for publication as Proposed Standard.



Cheers



Dacheng