Last Call Review of draft-sweet-rfc2910bis-08
review-sweet-rfc2910bis-08-genart-lc-miller-2016-08-04-00

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

Summary:

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
   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
  3.1.1".

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
  ignored.

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


-- 
- m&m

Matt Miller
Cisco Systems, Inc.



Attachment:


signature.asc




Description:

 OpenPGP digital signature