[Gen-art] Telechat Review of draft-sweet-rfc2910bis-08

Matt Miller <mamille2@cisco.com> Thu, 04 August 2016 01:14 UTC

Return-Path: <mamille2@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4410712D0A8; Wed, 3 Aug 2016 18:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Status: No, score=-15.808 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5mg20r5fYzzw; Wed, 3 Aug 2016 18:14:39 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767FF12B028; Wed, 3 Aug 2016 18:14:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4950; q=dns/txt; s=iport; t=1470273279; x=1471482879; h=to:from:subject:message-id:date:mime-version; bh=BSbnjYNALS+KUb5Kik47GtaYbJoukHFOA2BQRkWUti0=; b=AC2FIEfd8VVBnlMldzgl0Z+2GV1BF6+GFbp4y0onFvRfcjhKmc0LLeN7 3G4ocRz9uzkVCx6b4o+qrVGjGndSNlDoC0DlDZuxjm6XhfwAQoJDLTPCf qCZBYx4OoD+rH4adsfOvwE0JqH96z0G77AWhR+1B4OmB6PUdac+TGy2Ib Q=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.28,468,1464652800"; d="asc'?scan'208";a="132050381"
Received: from alln-core-3.cisco.com ([]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Aug 2016 01:14:38 +0000
Received: from [] ([]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u741EOMA019122; Thu, 4 Aug 2016 01:14:27 GMT
To: gen-art@ietf.org, draft-sweet-rfc2910bis.all@ietf.org
From: Matt Miller <mamille2@cisco.com>
Message-ID: <9b8acaa9-36e4-28a0-59b1-c449751983c0@cisco.com>
Date: Wed, 03 Aug 2016 19:14:22 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="hrDkMr6HF7WXak59XIBwepe33RuQQLjiu"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/Qz4ckYCFmpnopeA6OcTJ7UtR2Ps>
Subject: [Gen-art] Telechat Review of draft-sweet-rfc2910bis-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Aug 2016 01:14:41 -0000

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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >.

Document: draft-sweet-rfc2910bis-08
Reviewer: Matthew A. Miller
Review Date: 2016-08-03
IETF LC End Date: 2016-07-11
IESG Telechat date: 2016-08-04


Almost ready.  My one major issue is with the digest authentication
requirements, and really needs to be addressed in a way that
accounts for current security best practices.

I admit that I did not read the RFCs this document obsoletes.

I did not validate the correctness of any of the examples in
Appendix A.

Major issues:

* In Section 8.1.1. "Digest Authentication", support for MD5 and
  MD5-sess is a MUST, which contradicts the NOT RECOMMENDED in
  RFC 7616.  I this is likely because of the giant number of existing
  implementations, but it's a bad idea to continue the practice given
  how compromised MD5-based schemes are.  Maybe the following helps
  find something acceptable?

   IPP Clients and Printers SHOULD support Digest Authentication
   [RFC7616].  For compatibility with existing implementations,
   Clients and Printers SHOULD implement and support MD5 and MD5-sess.
   However, MD5 and MD5-sess are NOT RECOMMNEDED for newer
   implementations.  Use of the Message Integrity feature
   (qop="auth-int") is OPTIONAL.

Minor issues:

* The "meta-data" states this document obsoletes 2910 and 3382,
  but the Abstract does not explicitly say this.  There is the
  editor's note, but it is helpful to put at least a mention in
  the Abstract.

* In Section 3.2. "Syntax of Encoding", the ABNF in Figure 10 does
  not parse in the tools I tried, because of the duplicate
  reference.  The following seems to me to accomplish the intent
  while still parsing:

   delimiter-tag = begin-attribute-group-tag  / ; see section 3.5.1
             end-of-attributes-tag /
   future-delimiter-tag = %x06-0F               ; see section 3.5.1
   begin-attribute-group-tag = %x00 / operation-attributes-tag /
      job-attributes-tag / printer-attributes-tag /
      unsupported-attributes-tag /  %x06-0F
   operation-attributes-tag =  %x01                ; tag of 1
   job-attributes-tag      =  %x02                 ; tag of 2
   printer-attributes-tag =  %x04                  ; tag of 4
   unsupported-attributes-tag =  %x05              ; tag of 5

* Section 3.3. "Attribute-group", the last row in Table 1 indicates
  the document content is "in a special position as described above",
  which appears to be Section 3.1.1.  It seems better to be more
  explicit and say "in a special position as described in Section

Nits/editorial comments:

* idnits complains that this document is attempting to reference
  "rfc2910bis" (this document) without declaring the reference.
  These are all in the IANA Considerations, so it seems enough to
  me to change them to "this document".

Non-nits comments:

* idnits is complaining about "weird spacing" in a number of places,
  but they are clearly part of a table (which is the sole content of
  the containing section/appendix), and I think can be safely

* idnits is complaining about a downref to RFC2818, but it's
  already on the Downref Registry.

- m&m

Matt Miller
Cisco Systems, Inc.