Re: IANA considerations
Bruce Lilly <blilly@erols.com> Thu, 07 July 2005 14:28 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXMq-0007Xl-FH; Thu, 07 Jul 2005 10:28:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXMp-0007Wq-6t for ietf@megatron.ietf.org; Thu, 07 Jul 2005 10:28:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11984 for <ietf@ietf.org>; Thu, 7 Jul 2005 10:28:40 -0400 (EDT)
Received: from ns3a.townisp.com ([216.195.0.136] helo=ns3.townisp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqXnz-0002nM-EQ for ietf@ietf.org; Thu, 07 Jul 2005 10:56:49 -0400
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id 64A8629923 for <ietf@ietf.org>; Thu, 7 Jul 2005 10:28:39 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67ESbap024669(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 10:28:37 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67ESYgt024668(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 10:28:35 -0400
From: Bruce Lilly <blilly@erols.com>
Organization: Bruce Lilly
To: ietf@ietf.org
Date: Thu, 07 Jul 2005 10:28:27 -0400
User-Agent: KMail/1.8.1
References: <46uc7l$ghvi33@mx14.mrf.mail.rcn.net>
In-Reply-To: <46uc7l$ghvi33@mx14.mrf.mail.rcn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507071028.28861.blilly@erols.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Subject: Re: IANA considerations
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
John Klensin wrote: > That said, I think we should be paying careful attention to > Bruce's implied suggestion about how template > boilerplate-generators should be constructed. Some clarification: 1. In the specific case of the troff/nroff rfc macros and template, Ned's characterization of the text as boilerplate is inaccurate. True boilerplate (IPR boilerplate, Copyright notices, Status of this Memo, RFC-Editor funding Acknowledgment, even the canned versions of IESG notes) are contained in the macro package, not visible in an author/editor's source document and not emitted until the document is formatted. The template is provided as a convenience for authors/editors, and has some template text corresponding to the basic recommended RFC structure, some hints on how to do things such as include text that is present in a draft but disappears in RFC form (e.g. a draft change history), etc. An author/editor is of course free to ignore the template completely, using the macros with a source document created from scratch, or modified from another source document. The case might well be different for other means of generating drafts and RFCs, where a "boilerplate" characterization might be apropos, but it is not in this instance. "Placeholder" would be a suitable term. 2. I posted what I had put in the template; others are of course free to do nothing at all, to do something completely different, to do something similar, or even to use the same text verbatim (it is not copyrighted). I added the "...presence of this template text..." part about 3 weeks ago during early parts of this discussion. I thought it was a reasonable thing to do at the time, and I still think so (if anything, I might be inclined to remove or comment out the "no IANA considerations" text, which is in fact suggested wording for that specific case and it appears on a single source line with the other text (so failure to edit gets the whole thing, and explicit action is required to make any change, whether that's to remove the warning or to substitute real considerations). I'm not presuming to suggest that others should do likewise. They are free to do so, but to the extent that some people think that I'm some sort of whacko, they might be inclined to do something contrary, and they are of course also free so to do. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: IANA considerations Bruce Lilly
- Re: IANA Considerations Bruce Lilly