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

[Benjamin Kaduk <[e-mail]>]

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