Re: [Jmap] [Last-Call] secdir review of draft-ietf-jmap-quotas

[Bron Gondwana <[e-mail]>]

Rene, can you please address this review.  Hopefully we're close to ready now!

Thanks,

Bron.

On Thu, Jan 12, 2023, at 09:06, Wes Hardaker wrote:
> 
> I have 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 editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> Review summary: almost ready with issues
> 
> Apologies for my delay in getting to the new version of this document
> (between vacation and a bad cold, I got behind in tasks).  Thank you for
> the work you put into the new version; I find it much better than the
> old and can see you took many suggestions (mine and others) into
> account.
> 
> A few (mostly minor) thoughts on the new version:
> 
> - If it were me, I'd break the quota attributes section into it's own
>   (becoming a new 4.1) starting with "The quota object MUST...".
> 
> - 4.1: document at section 5.1 -> document in section  5.1
> 
> - 4.3: any of which may be omitted -> any of which may be included or
>   omitted
> 
> - 4.3: seems odd that the name attribute is the only one that isn't a
>   list.
> 
> - 4.3: Larger issue wrt interoperability: My last note leads to the
>   next: in the summary paragraph you state "A Quota object matches the
>   FilterCondition if and only if all the given conditions match,
>   including multiple array elements existing within a condition.", which
>   I don't know how to interpret properly.  You say that all conditions
>   match (which I'm sure means if both a scope and a resourceType are
>   specified they both MUST match).  But the second part of the sentence
>   leaves me confused about multiple array elements.  This would leave me
>   to think that if you specified multiple resourceTypes in a list, then
>   every type must match which should never be true so I doubt this is
>   what you mean.  Maybe this is a good rewrite:
> 
>       A Quota object matches the FilterCondition if and only if all the
>       given properties match (i.e. a logical and of all properties).
>       For filter properties that are a list, at least one of the list
>       elements must match for that property to be considered a match
>       (i.e. a logical or of all the property's list element).
> 
>   But...  I am trying to figure out what you mean, and my interpretation
>   may be wrong!
> 
> - For the example in section 5.2, I'd suggest actually using data that
>   followed the previous example in a time-sequence.  Thus, if you
>   changed the "sinceState" to "78540" to match the last value from the
>   previous example, it would better show an example of commands over
>   time.  (IMHO)
> 
> - The security section is improved (thank you), but there are some
>   wording issues within it that need work:
> 
>     - "so he shouldn't know" -- I think you mean other users here
>       shouldn't know.  So I'd change this to "so other users shouldn't
>       know" or "no users should know".
> 
>     - The last sentence is hard to read as is.  I'd suggest the
>       following replacement:
> 
>       In order to limit those attacks, quotas with "domain" or "global"
>       scope SHOULD only be visible to server administrators and not to
>       general users.
> 
> - I'm surprised you don't have an acknowledgment section, which
>   customary to list all the people that help you put this specification
>   together.  It's common but not required of course.
> 
> 
> -- 
> Wes Hardaker
> USC/ISI
> 
> -- 
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]