[apps-discuss] APPSDIR review of draft-ietf-httpbis-p7-auth-24
S Moonesamy <sm+ietf@elandsys.com> Wed, 30 October 2013 04:48 UTC
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF51621F9D22; Tue, 29 Oct 2013 21:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.896
X-Spam-Level:
X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CZzIqcyhUhy; Tue, 29 Oct 2013 21:48:02 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D19F21F9D46; Tue, 29 Oct 2013 21:44:45 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U4gwbp023165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 21:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383108222; bh=nZrZ+ivyJh+jBc4JoipycAe5Kppgbh+yM+wmlYezyhU=; h=Date:To:From:Subject:Cc; b=hlptHRWikGlzJMlCeRV7HAEtgXKlSxkabxypcqcMDG1b+D/9WzkIabBTNTNmlagYx GApt7IVcMI66GFCsCFTOn92uj3vfbgUeTmQ5LoXSUewMjcuzm7/CpViII8tGyMDEiR Hy2bamS6uOYyZyXqn4sOFbgdxVTu+Gxb2WDp83uc=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383108222; i=@elandsys.com; bh=nZrZ+ivyJh+jBc4JoipycAe5Kppgbh+yM+wmlYezyhU=; h=Date:To:From:Subject:Cc; b=qjgzVYN9pmGrKeTR/T1Cv0ap5fCSGcbRGkOk/hBAhyiaY8kI42zcAWuFL+7MPBe6t 9wY+3lCbABdC3lS6WdfSt3pKaQR+D2YoC1hWRLO8cJQZiDRYtpcmtYMNEDncsiusSd dQd8qt3qo2KqrPiJ/NPdYofgevB44Z9PwwOB7y4k=
Message-Id: <6.2.5.6.2.20131029152147.0c123670@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 29 Oct 2013 17:48:20 -0700
To: apps-discuss@ietf.org, draft-ietf-httpbis-p7-auth.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p7-auth-24
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2013 04:48:03 -0000
I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-p7-auth-24 Title: Hypertext Transfer Protocol (HTTP/1.1): Authentication Reviewer: S. Moonesamy Review Date: October 29, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft is almost ready for publication as a Proposed Standard. This document defines the HTTP Authentication framework. The document is well-written and clear. Major Issues: None Minor Issues: In Section 1: "HTTP provides several OPTIONAL challenge-response authentication schemes that can be used by a server to challenge a client request and by a client to provide authentication information." I suggest using RFC 2119 after Section 1.2. Nits: In Section 2.1: "Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information." The RFC 2119 "may" is unnecessary. Regards, S. Moonesamy