Subject: [Dime] Mirja Kühlewind's No Objection on draft-ietf-dime-doic-rate-control-10: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 21 Jan 2019 07:04:20 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dime-doic-rate-control-10: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/

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

The security considerations of rfc7683 have an own section on non-complaint
nodes (section 10.3). While this is discussed in rfc7683, I think it is
especially important for this document to remind the reader that there may be
non-compliant nodes that may send with a higher than indicated rate. I would
recommend to add one more statement to the security considerations section of
this doc and potentially point the reader explicitly at section 10.3 of rfc7683.

Two comments on normative language:

1) Section 5.6: "Any algorithm implemented MUST result in the
      correct rate of traffic being sent to the reporting node."
I would recommend to maybe change this to:
"Any algorithm implemented MUST correctly limit the maximum
 rate of traffic being sent to the reporting node."
Otherwise I would think this is hard to implement in practice.

2) Section 7.2: "... the reporting node MUST periodically evaluate its overload
state..." Not sure if the normative language is really appropriate here as this
does not impact interoperability, nor can be checked. If at all, I guess I
would recommend a "SHOULD" instead.

And two more editorial comments:

1) As section 7.3 only describes (in quite some detail) an example algorithm, I
would rather have put this in an appendix. But I guess that's a matter of
taste...

2) I don't think section 8.2. is needed.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 24 Jan 2019 17:34:46 -0600

Mirja,

Thanks for the comments.  I've updated the document per my replies below.

Regards,

Steve

> https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/
SRD> I can add a statement if people feel strongly about it.  It does
seem a bit redundant as the first paragraph of the security
considerations section already has a reference back to the security
considerations section of rfc 7683.
> Otherwise I would think this is hard to implement in practice.
SRD> I like your wording better and have updated the document accordingly.
> would recommend a "SHOULD" instead.
SRD> I agree in principle but this was carried over from RFC7415 upon
which the rate algorithm is based.  I suggest changing it to SHOULD
unless there are other objections.
> would rather have put this in an appendix. But I guess that's a matter of
SRD> If I remember correctly, this was an appendix at one point and got
moved to a section.  I'd prefer to leave it as is given it is a matter
of taste.
> 2) I don't think section 8.2. is needed.
SRD> I'll remove it unless I hear any objections to the suggestion.
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime