Re: [secdir] Secdir telechat review of draft-ietf-secevent-token-07

[Mike Jones <[e-mail]>]

Hi Russ (and Ben),

Thanks for the useful review, Russ. https://tools.ietf.org/html/draft-ietf-secevent-token-08 is intended to address your review comments.  See the inline responses below.

				-- Mike

-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: Wednesday, March 28, 2018 5:59 AM
To: Russ Housley <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Secdir telechat review of draft-ietf-secevent-token-07

Hi Russ,

On Tue, Mar 27, 2018 at 01:44:55PM -0700, Russ Housley wrote:
> Reviewer: Russ Housley
> Review result: Has Issues
> 
> I reviewed this document as part of the Security Directorate's ongoing 
> effort to review all IETF documents being processed by the IESG.  
> These comments were written primarily for the benefit of the Security 
> Area Directors.  Document authors, document editors, and WG chairs 
> should treat these comments just like any other IETF Last Call comments.
> 
> Document: draft-ietf-secevent-token-07
> Reviewer: Russ Housley
> Review Date: 2018-03-27
> IETF LC End Date: unknown
> IESG Telechat date: 2018-05-10
> 
> Summary: Has Issues
> 
> Process concern
> 
> A request for a telechat review of draft-ietf-secevent-token was 
> assigned to me.  However, there has not yet been an IETF Last Call 
> announced for this document.

Thanks for the review, and for pointing out the process nit.
Getting on a telechat is pretty hard at the moment due to the large spike in documents we saw prior to the IESG cutover.  I should still have time to complete my AD review and issue the IETF LC with time to spare before 2018-05-10, though.

Authors, please feel free to address Russ's comments in a new revision if you can do so before the IETF LC is issued.

Thanks,

Ben

> 
> Major Concerns
> 
> All of the examples in Section 2.1 are non-normative.  Instead of 
> staying that in each of the subsections, please add some text at the 
> top of Section 2.1 that says so.

Done

> I do not understand the first paragraph of Section 3.  I think you are 
> trying to impose some rules on future specifications that use SET to 
> define events.  Please reword.

I reworked the beginning of the paragraph to try to provide more context for the statements that follow.
 
> Minor Concerns
> 
> The Abstract says:
> 
>    ...  This statement of fact
>    represents an event that occurred to the security subject.  In some
>    use cases, the security subject may be a digitial identity, but SETs
>    are also applicable to non-identity use cases.  ...
> 
> Please correct the spelling of digital identity.

Done (but then removed, per the next item)

> I do not think this tells the reader when they might want to employ 
> this specification.  The following sentence from the Introduction does 
> a better job:
> 
>    This specification is scoped to security and identity related events.

I replaced the previous statement in the abstract with a version of the sentence from the introduction that you cited.

> In Section 2, the last bullet on page 5 talks about the "events" JSON 
> object.  The last sentence caught me by surprise, and I had to read it 
> a few times to figure out the intent.  The events object cannot be 
> "{}", but the payload for an event in that object can be "{}".  I 
> think that a MUST statement about there being at least one URI string 
> value would have helped me.

The MUST statement that you asked for is now there (at the end of the previous bullet item, where it makes better sense).

				Thanks again,
				-- Mike