Skip to main content

Last Call Review of draft-ietf-kitten-krb-auth-indicator-04
review-ietf-kitten-krb-auth-indicator-04-genart-lc-sparks-2016-12-22-00

Request Review of draft-ietf-kitten-krb-auth-indicator
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-01-06
Requested 2016-12-16
Authors Anupam Jain , Nathan Kinder , Nathaniel McCallum
I-D last updated 2016-12-22
Completed reviews Genart Last Call review of -04 by Robert Sparks (diff)
Opsdir Last Call review of -06 by Scott O. Bradner (diff)
Secdir Last Call review of -04 by Christian Huitema (diff)
Secdir Last Call review of -06 by Christian Huitema (diff)
Genart Telechat review of -06 by Robert Sparks (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-kitten-krb-auth-indicator by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 07)
Result Ready w/nits
Completed 2016-12-22
review-ietf-kitten-krb-auth-indicator-04-genart-lc-sparks-2016-12-22-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

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