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

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Mar 19, 2014 at 11:31 PM, Shaun Cooley (shcooley) <
[e-mail]> wrote:

>  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:
>
>
>
> - 6.1.1.2 - two uses of SHOULD NOT
>
> - 6.1.1.3 - two uses of SHOULD
>
> - 6.1.1.7 - two uses of SHOULD
>
> - 6.2.1.1 - one use of SHOULD
>
> - 6.2.1.2 - one use of RECOMMENDED
>
> - 6.2.1.3 - two uses of RECOMMENDED
>
>
>
> I don't see why we wouldn't want to include normative language in the
> Security Considerations - especially SHOULD.  The definition from
> BCP14/RFC2119 of "*there may exist valid reasons in particular
> circumstances to ignore a particular item, but the full implications must
> be understood and carefully weighed before choosing a different course*"
> seems like exactly what the Security Considerations are getting at: "the
> authors thought about this, and suggest you do X, unless you have a
> specific reason and fully understand the implications of not following the
> authors' suggestion".
>
>
>
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.  It would appear this
opinion has formed since RFC3552 was published, since obviously there's a
conflict between them.  But like I said, it does seem to vary depending on
who and when one is asking.  Could also be the person(s) who told me this
are actually plain wrong.

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

-MSK