Re: [Ecrit] Mirja Kühlewind's No Objection on draft-ietf-ecrit-data-only-ea-21: (with COMMENT)

[Brian Rosen <[e-mail]>]

Thanks for your comments.

There is no rate limit for MESSAGE.  I will add text that discusses it.  As a practical matter, a person is involved in every message, so the rate has to be very slow.  While the systems that deal with these messages have to be hardened against DoS of all forms, I agree the text should discuss the issue and at least offer some guidance.

I will also add text to Security Considerations, since DoS is a consideration.

Yes, both of those musts should be MUSTs. I will fix that.

Brian


> On Feb 28, 2020, at 1:23 PM, Mirja Kühlewind via Datatracker <[e-mail]> wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-ecrit-data-only-ea-21: 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-ecrit-data-only-ea/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> One question: Should non-inactive SIP MESSAGEs be rated-limited somehow or it
> that already specified in the SIP spec (sorry don't know that by heart ;-)? If
> so a pointer would probably be good. Or maybe another thing to add to section 7
> (or a subsection or an own section) or alternatively to the security
> considerations section I guess.
> 
> One small comment/nit:
> Sec 5.2:
> "AlertMsg-Error values sent in
>   provisional responses must be sent using the mechanism defined in
>   [RFC3262]; or, if that mechanism is not negotiated, it must be
>   repeated in the final response to the transaction."
> Maybe two times MUST?
> 
> 
>