[Gen-art] Review of draft-ietf-kitten-krb-auth-indicator-04
Robert Sparks <email@example.com> Thu, 22 December 2016 19:41 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 542D9128874; Thu, 22 Dec 2016 11:41:12 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Robert Sparks <firstname.lastname@example.org>
Date: Thu, 22 Dec 2016 11:41:12 -0800
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Subject: [Gen-art] Review of draft-ietf-kitten-krb-auth-indicator-04
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2016 19:41:12 -0000
Reviewer: Robert Sparks Review result: Ready with Nits 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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-kitten-krb-auth-indicator-?? Reviewer: Robert Sparks Review Date: 2016-12-22 IETF LC End Date: 2017-01-06 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as Proposed Standard, but with nits that should be considered before advancing Nits/editorial comments: Please remove the 2119 MUST from the Introduction - you already have that requirement expressed in the last paragraph of section 3. If the introduction needs to highlight that the requirement exists, say something similar to "Section 3 requires that elements of this type appear within an AD-CAMMAC container." The 3rd paragraph in section 4 has a MAY in its first sentence that is not an appropriate use of 2119. A lower case "may" is fine here - you're not placing a requirement on implementation. That whole 3rd paragraph looks like an attempt to acknowledge a larger conversation without getting into the meat of that conversation. Rather than make the readers re-discover the problem on their own (right now they have to guess at what the problem really is, with your suggested guidance being the only hint), can you explicitly demonstrate the potential problem? Perhaps pointing to existing discussion in another document would be good? There's bound to be something in our various policy framework documents that captures why you need either only positive or only negative assertions if you are going to be combining them. We ran into pretty much this problem with presence - grep for "positive grants" in RFC5025 for instance. I suspect there's a better reference that I'm just not remembering at the moment.
- [Gen-art] Review of draft-ietf-kitten-krb-auth-in… Robert Sparks
- Re: [Gen-art] Review of draft-ietf-kitten-krb-aut… Benjamin Kaduk
- Re: [Gen-art] Review of draft-ietf-kitten-krb-aut… Jari Arkko