Review of draft-ietf-kitten-krb-auth-indicator-04

Robert Sparks <rjsparks@nostrum.com> Thu, 22 December 2016 19:41 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
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)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
To: <gen-art@ietf.org>
Subject: Review of draft-ietf-kitten-krb-auth-indicator-04
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148243567232.26011.10783984451734200377.idtracker@ietfa.amsl.com>
Date: Thu, 22 Dec 2016 11:41:12 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/LE6k88FkWZdvJ0b3IgalBaPLvKQ>
Cc: kitten@ietf.org, draft-ietf-kitten-krb-auth-indicator.all@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?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.