Subject: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-quota-07: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 18 Oct 2021 09:55:29 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-extra-quota-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-quota/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 8.  Should the prohibition on revealing quota information be a bit
stronger? OLD In
   particular, no quota information should be disclosed to anonymous
   users.

NEW
In particular, quota information SHOULD be disclosed only to authenticated and
authorized users

** Section 8.  Should it be noted that computing remaining resources might
incur a load on the server.  Implementers might want to rate limit or return
less precise computations when under higher load?

** Typos
Section 3.2.  Typo. s/arbitary/arbitrary/

Section 3.2.  Typo. s/dependant/dependant/

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2021 13:13:28 +0100

Hi Roman,

Thank you for your comments.

All QUOTA commands are only available once the user is authenticated. 
However this gets a bit complicated, because "anonymous" users are 
classes as authenticated in SASL framework (when SASL ANONYMOUS 
authentication mechanism is used).

What I am trying to say is that the current text is actually more strict 
than some interpretations of your text.

In regards to "and authorized". Historically there are no per user 
control in server implementations about who can see quota information. I 
am a bit doubtful that server implementations would implement such 
control unless there is clearly provided benefits.

> less precise computations when under higher load?
I see your point. I am more inclined to recommend caching this 
information. I've added some text on this.
> Section 3.2.  Typo. s/dependant/dependant/
Thanks, I already fixed these.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 21 Oct 2021 12:23:02 +0000

Hi Alexey!

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Alexey Melnikov
> Sent: Thursday, October 21, 2021 8:13 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]
> Subject: Re: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-quota-
> 07: (with COMMENT)
> 
> Hi Roman,
> 
> > ** Section 8.  Should the prohibition on revealing quota information
> > be a bit stronger? OLD In
> > In particular, quota information SHOULD be disclosed only to
> > authenticated and authorized users
> 
> However this gets a bit complicated, because "anonymous" users are classes as
> authenticated in SASL framework (when SASL ANONYMOUS authentication
> mechanism is used).
> 
> What I am trying to say is that the current text is actually more strict than
> some interpretations of your text.
> 
> In regards to "and authorized". Historically there are no per user control in
> server implementations about who can see quota information. I am a bit
> doubtful that server implementations would implement such control unless
> there is clearly provided benefits.

Understood.  Thanks for explaining.  I didn't appreciate those mechanics in SASL and was thinking that "anonymous" was "anyone who can connect to the port".

> > ** Section 8.  Should it be noted that computing remaining resources
> > might incur a load on the server.  Implementers might want to rate
> > limit or return less precise computations when under higher load?
> I see your point. I am more inclined to recommend caching this information.
> I've added some text on this.
> > ** Typos

Thanks for all of the above.

Regards,
Roman