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

[Phil Hunt <[e-mail]>]

Russ

Thanks for your review. I am away on holiday but hope to find an opportunity to get back to you on your review in the coming days. 

Thanks,

Phil

> On Mar 27, 2018, at 1:44 PM, Russ Housley <[e-mail]> 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.
> 
> 
> 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.
> 
> 
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=fnyJdKvhWPUuMKKzm5d_t3Zs2s0pL22w8NMEZhfDYj0&s=5bt_aLpKCABqLuxercRiolomH_tFBb33PQnY1KM3CuE&e=