Hi Robert, Thanks for the review (I'm the shepherd, not the editor). On Thu, Dec 22, 2016 at 11:41:12AM -0800, Robert Sparks wrote: > 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. Those first two comments look like good changes to me. > 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. This is also a good point, but I'm not sure I have a good suggestion of a reference to insert. To give a more concrete example relevant to this document, at the moment, you can authenticate to kerberos in many ways, including with a password, using an OTP value (within a RFC 6113 FAST tunnel), and with PKINIT asymmetric crypto. One might be tempted to put in a value "without-password" to indicate that a password was not used, but when an application server goes to consume that authentication indicator, the assumption might be that without-password means PKINIT, which is arguably a stronger authentication than the OTP method. Thus, there is the possibility of the application server would make a bad decision based on the negative "without-password" indicator, in contrast to an explicit "pkinit" or "otp" indicator. -Ben