Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field

[Barry Leiba <[e-mail]>]

>> While RFC 3552 ("Guidelines for Writing RFC Text on Security
>> Considerations") does not specify whether or not Security Considerations
>> should include normative language, both of the examples in section 6 (SMTP
>> and VRRP) include normative language:

First, let's please separate "2119 key words" from "normative
language", and be sure we don't fall under the mistaken impression
that language isn't normative unless it's in all caps.  If a Security
considerations section says, "Farble attack is possible if you don't
wiffle, so it's essential that servers wiffle," that's a normative
requirement for servers to wiffle, whether or not the magic word
<strike>"please"</strike> "MUST" is used.

Now...

> I can't recall the exact reason why it's been said that RFC2119 language
> ought not be used in Security Considerations (or similar) prose, or which
> document's development cycle brought it up, but my general recollection is
> that those words were intended to convey aspects of interoperability having
> to do with protocol elements, and not otherwise.

That's the silliest thing I've ever heard.[1]

May I disabuse y'all of that idea forthwith?  Yes?  Good.  Thank you.

The document tells us how to implement the protocol.  The whole
document does, from the tippy-top of the Introduction head to the
soles of the References feet.  Normative stuff can appear anywhere,
and if it makes sense to put some in the Security Considerations
section, then that's where we should put it.

Now, I *would* have an issue with the organization of the document if
protocol elements were defined only in the Security Considerations,
and there might be times when security aspects should be normatively
specified where the protocol elements were defined, and only
highlighted in the Security Considerations, or whatnot.  But that's a
question of organization of a particular document.  This document is
well organized, and I have no issues with that.

So if you (for whatever value of "you", which here seems like Shaun,
with Murray in basic agreement) think that the normative language in
the Security Considerations is not sufficiently clear or strong, and
would benefit from some 2119 key words, make it so.  Do it with care
and thought, but don't have any silly ideas that 2119 key words don't
belong in security considerations sections.  They belong where they
are needed, and not where they aren't.

> I'm happy to take direction from the sponsoring AD on this one.

So let it be written; so let it be done.

Barry

[1] Actually, not really: I've heard some pretty damnfool things in my
life, some far sillier than any of us can imagine.  But a little
hyperbole never hurt an argument.