Re: MUSTs and SHOULDs [was RE: [Sipping] new draft on overload control in SIP]

[Dean Willis <[e-mail]>]

On Feb 28, 2006, at 2:06 AM, Juha Heinanen wrote:

> Jonathan Rosenberg writes:
>
>> I agree completely with Dan here. I've done this in various  
>> places, but
>> its very difficult to do. The point though, is that ultimately,
>> implementors do what they want and/or can get away with.
>
> this major vendor has OFFICIAL policy that they don't accept bug  
> reports
> against SHOULD and MAY violations. it ha nothing to do with  
> implementors
> who write the code.  i have got an impression that the implementors of
> this major company are not ALLOWED to fix such bugs even if they want
> to.

You have my blessing to call them idiots, even if I happen to work  
there. Of course, I doubt you ever needed my blessing for that . . .  
What's the Finnish word for idiot, anyhow? I'm sure I've overheard it  
in some of those standards discussions after I've said something  
"controversial", but it would be nice to know. One can never know too  
many insults, they're such handy words.

Seriously, we have historically badly over-used the requirements  
language of RFC 2119. We've often used it to describe how things  
normally work. It should be used only to explain the consequences of  
deviations from normalcy. Note that simply saying "MUST do X" or  
"SHOULD do Y" doesn't really explain these consequences.

IMHO, each usage of 2119 language outside of a "pure requirements  
document" (and arguably even in those) needs to be accompanied by  
justification.

MUST: If you deviate from this, the indicated dire consequences are  
very likely to occur, and no work-around or alternative is defined.  
The default dire consequences here are "protocol simply won't work",  
but usually more is needed.

SHOULD: If you deviate from this (which you might need to do for some  
use cases), you need to take care of some extra points (described  
here), or the indicated dire consequences are very likely to occur.

MAY: Here's some extra stuff you might choose to do, if you've dealt  
with the consequences, which including making sure that the other  
affected elements are prepared to deal with this optional behavior.  
If you fail to verify that other affected elements are prepared to  
deal with the optionality, you must be prepared to deal with them  
either ignoring the optionality, rejecting the request, or failing in  
an unpredictable way, possibly catastrophic.


Good example, from draft-ietf-sipping-uri-services-05.txt:

    Attackers may attempt to send a URI-list containing URIs whose host
    parts route to the victims of the DoS attack.  These victims do not
    need to be SIP nodes; they can be non-SIP endpoints or even routers.
    If this attack is successful, the result is that an attacker can
    flood with traffic a set of nodes, or a single node, without needing
    to generate a high volume of traffic itself.

    There are several measures that need to be taken to prevent this  
type
    of attack.  The first one is keeping unauthorized users from using
    URI-list services.  So, URI-list services MUST NOT perform any
    request explosion for an unauthorized user.  URI-list services MUST
    authenticate users and check whether they are authorized to request
    the service before performing any request fan-out.

This actually places one requirement, redundantly using a MUST and a  
MUST NOT with opposing descriptions, backed up by a description of  
what will go wrong if you fail to meet the requirement --  
susceptibility to a range of attacks.


Bad example from draft-ietf-sipping-uri-list-message-05.txt:

    A UAC that wants to create a multiple-recipient MESSAGE request MUST
    create a MESSAGE request according to RFC 3428 [8] Section 4.  The
    UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the
    MESSAGE URI-list service.  In addition to the regular instant  
message
    body, the UAC SHOULD add a URI-list body whose Content-Disposition
    type is 'recipient-list', specifed in the Framework and Security
    Considerations for SIP URI-list Services [11].  This body contains a
    URI-list with the recipients of the MESSAGE.  The URI-list body MAY
    also include the 'capacity' extension to the URI-list specified in
    Section 4.1.  The UAC MUST also include the 'recipient-list-message'
    option-tag, defined in Section 5, in a Require header field.


Let's look at the "requirements" in the above.

MUST #1 (create a message request): Why MUST we create a message  
request? What failure of interoperability occurs if we don't create a  
message request? We're really trying to say that this service only  
understands MESSAGE requests as defined in RFC 3428, and that it  
won't work if you were to use some other kind of request.

SHOULD #1 (populate the request URI): What are the alternatives? What  
would we want to put in the request URI other than the URI of the  
target? What happens if we were to put something else here, and how  
would we compensate if we did? Really, we're not trying to define a  
requirement here -- we're just describing a use case.

SHOULD #2 (add a URI-list body): Again, what are the alternatives?  
We're not defining any here. We're just trying to describe a use case.

MAY #1 (also include the 'capacity' extension): Why would we want to  
do that? Fortunately, the "why" is defined in the referenced section  
4.1. But are we stating an aspect of optionality that affects  
interoperability? Nope. We're just describing some information that,  
if present in the request, will be used in processing the request at  
the recipient, and if it's not there, it won't be.

MUST #2 (also include the 'recipient-list-message" option tag): It  
would be nice to say WHY we do this, although we use this in SIP so  
much we seem to expect the reader to know. In short, we're using the  
extension-negotiation mechanism of SIP to make sure that the  
recipient understands this extension. If we include the option-tag,  
then a recipient of this request will reject the request with an  
informative error if it does not understand the extension.


My suggested rewrite:

    A UAC that wants to create a multiple-recipient MESSAGE request
    creates a MESSAGE request according to RFC 3428 [8] Section 4.  The
    UAC populates the Request-URI with the SIP or SIPS URI of the
    MESSAGE URI-list service.  In addition to the regular instant  
message
    body, the UAC adds a URI-list body whose Content-Disposition
    type is 'recipient-list', specifed in the Framework and Security
    Considerations for SIP URI-list Services [11].  This body contains a
    URI-list with the recipients of the MESSAGE.  The URI-list body may
    also include the 'capacity' extension to the URI-list specified in
    Section 4.1.  The UAC MUST also include the 'recipient-list-message'
    option-tag, defined in Section 5, in a Require header field.

Note that the only 2119 language retained here is the final MUST on  
extension negotiation. And only the hope that the negotiation  
mechanism is well-understood justifies our not saying more here. Were  
I to re-write this again, I would change the closing sentence to be:

    The UAC MUST also include the 'recipient-list-message'
    option-tag (defined in Section 5) in a Require header field,
    which will result in rejection of this request by any UAS
    that does not implement this extension.


Now, Miguel didn't take all my suggestions. Instead, he produced the  
following in -07

    A UAC that wants to create a multiple-recipient MESSAGE request
    creates a MESSAGE request that MUST be formatted according to RFC
    3428 [8] Section 4.  The UAC populates the Request-URI with the SIP
    or SIPS URI of the MESSAGE URI-list service.  In addition to the
    regular instant message body, the UAC adds a URI-list body whose
    Content-Disposition type is 'recipient-list', specified in the
    Framework and Security Considerations for SIP URI-list Services  
[11].
    This body contains a URI-list with the recipients of the MESSAGE.
    Target URIs in this body MAY also be tagged with the 'capacity' and
    'anonymize' attributes specified in the XML Format Extension for
    Representing Capacity Attributes in Resource Lists [12].  The UAC
    MUST also include the 'recipient-list-message' option-tag,  
defined in
    Section 5, in a Require header field.

He still has two MUSTs that one has to dereference (but there ARE  
references given), and a MAY (which is also referenced). All the 2119  
language that doesn't have a real functional requirement attached to  
it has been removed. While it's not as pretty as mine (opinion), it's  
at least testable for compliance, and the important aspects of the  
"required" behavior can at least be extracted from the specification.


--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP