--On Friday, September 10, 2010 04:27:38 PM +0100 Elwyn Davies
<[email protected]> wrote:
Thanks for the review, Elwyn.
Minor Issues:
s4.3, para 3: The 'MUST' is not enforceable: certainly the client needs
to check it has got what it asked for but this isn't a protocol
requirement. Maybe s/the client MUST check to make sure/it is essential
for the client to check/
s6, para 4: As in s4.3, the first MUST is not enforceable.s/MUST/needs to/
s8, para 2: same problem again.
Contrary to popular belief, requirements language does not have to be
"enforceable" in order to be meaningful and appropriate. In each of the
cases cited, "MUST" is used to call out behaviors which are required
because they are essential to the security of the protocol extensions
defined in this document. I don't see any need for a change here.
Nits/editorial:
Except for one, the items in this part of your review are straightforward
and will be taken care of in the next update. The exception is this:
s4.1, para 6: It might be helpful to give a little more guidance about
what might reveal the client's identity, or at least provide a pointer
back to s3's list of what *can* be included.
Unfortunately, we can't, and section 3 contains no such list.
Authorization data is an open-ended space in the protocol for carrying
information related to authorization; there's no way to enumerate which AD
types might reveal the client's identity. That's going to be dependent on
the particular extensions involved, which may or may not be standardized,
and quite possibly by policy.
-- Jeff
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
