comments on draft-bradner-key-words-02.txt
neal@bighorn.dr.lucent.com Mon, 23 December 1996 19:22 UTC
Received: from ietf.org by ietf.org id aa12460; 23 Dec 96 14:22 EST
Received: from ihgw2.lucent.com by ietf.org id aa12353; 23 Dec 96 14:20 EST
Sender: ietf-request@ietf.org
From: neal@bighorn.dr.lucent.com
Received: from drmail.dr.lucent.com by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id MAA03608; Mon, 23 Dec 1996 12:55:57 -0600
Received: by drmail.dr.lucent.com (4.1/EMS-L SunOS) id AA15956 for ietf@ietf.org; Mon, 23 Dec 96 12:01:03 MST
Received: from lever.dr.lucent.com by drmail.dr.lucent.com (4.1/EMS-L SunOS) id AA15935 for ietf@ietf.org; Mon, 23 Dec 96 12:00:56 MST
Received: by lever.dr.lucent.com (4.1/EMS-L SunOS) id AA20760; Mon, 23 Dec 96 11:00:56 PST
Date: Mon, 23 Dec 1996 11:00:56 -0800
Message-Id: <9612231900.AA20760@lever.dr.lucent.com>
Original-From: Neal McBurnett <nealmcb@bell-labs.com>
To: sob@harvard.edu, ietf@ietf.org
Subject: comments on draft-bradner-key-words-02.txt
Reply-To: Neal McBurnett <nealmcb@bell-labs.com>
Comments: Hyperbole mail buttons accepted, v04.01.
Source-Info: From (or Sender) name not authenticated.
I think this document is a good idea. Here are a few suggestions. In the "Abstract" section: > This document defines these words as they should be interpreted in > IETF documents. It would be helpful to be clearer about the intent here, and how this document should be used. E.g. should it be quoted, or referenced? This is proposed as a BCP, so certainly it doesn't affect the interpretation of standards which don't explictly refer to it. So I suggest changing "interpreted" to "used". How about this: This document defines these words as they should be used in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document MUST be interpreted as described in RFC xxxx. A clarification about whether it is encouraged or not in non-standards-track documents would also help. As it is, the abstract starts off talking about the standards track, as if it might only apply there, but it seems useful to use it in Experimental and Informationals RFCs also (perhaps with more disclaimers about how it is not the IETF who sanctions the requirements). Either way, some more clarity would help. >6. Security Considerations >... > way that can effect security risks. Careful consideration should be change "effect" to "affect". Cheers, Neal McBurnett <nealmcb@bell-labs.com> 503-331-5795 Portland/Denver Bell Labs Innovations for Lucent Technologies Formerly AT&T's systems and technology business http://bcn.boulder.co.us/~neal/ (with PGP key)