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

[Jari Arkko <[e-mail]>]

Thanks for your review, Matt!

I agree with the MD5 issue that you raise below. Stephen Farrell has raised this issue in his Discuss, and otherwise I would have. Your suggested text may be a way to fix Stephens Discuss, however. So authors please take note.

The other issues from your review should be handled by the authors, and I agree with those issues as well.

Thanks again for your review.

Jari

On 04 Aug 2016, at 03:14, Matt Miller <[e-mail]> wrote:

> 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.
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art