[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