[rfc-i] headers and boilerplates last minute proposal
touch at ISI.EDU
Thu Apr 9 13:25:21 PDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
I'm suggesting wordsmithing to this doc, of the directives on including
text, not to the text included.
I'm not sure how to interpret your comments - you seem to be saying
"don't oversmith the included text", which isn't what I was doing.
Can you explain if that makes it more clear, or if not, what the concern is?
John C Klensin wrote:
> --On Thursday, April 09, 2009 10:00 -0700 Joe Touch
> <touch at ISI.EDU> wrote:
>>> To get off "forever", we have to talk about the here and now.
>>> If not "upon approval", or "upon publication", what's a
>>> better way to capture that?
>> All RFCs are implicitly "when published, and forever until
>> overridden by subsequent publications", so restating that
>> repeatedly seems needless.
>> In standards, we use the present tense (MUST), or imperatives
>> (e.g., SHALL). There's no need for that particular language in
>> this doc because it isn't a standard; the equivalent is just
>> stating the fact or using lower-case "shall".
>> IMO, just say "The following text is included" or "shall be
> In fairness, Leslie is trying to respond, at least in part, to a
> concern of mine. Especially in the new model, it strikes me as
> a very bad idea for the community, or even the IAB, to be
> micromanaging the RFC Editor [function] to the extent of saying
> "put in exactly this text and put it in exactly this place". I
> don't want to spend time pulling up and flogging old examples,
> but that way of working has gotten us into a whole series of
> problems in the past. The minor (and therefore non-sensitive)
> ones have included imposition of spelling inconsistencies that
> the RFC Editor did not feel able to change, the separation of
> material that should have been together into different parts of
> the document, etc.
> In general, it also takes an RFC to change an RFC. If one says
> "The following text shall be included" then we are going to need
> another RFC and review process to change that text. There is
> not much wrong with that if one believes that this sort of
> review and tuning process is a good use of community time. My
> own view is that, as with the IPR situation, we should get
> principles laid out and then move on, stepping back in only if a
> real problem develops that the various groups who are supposed
> to be handling these problems cannot or will not solve. I'm
> certain the community is better off if you are doing protocol
> work rather than spending time on this sort of situation; I hope
> that is true for me too.
> So I have encouraged Leslie to take a "this is guidance and
> initial text" approach, leaving the details and their evolution
> to the Style Manual effort, review of that Style Manual by the
> IAB, and calls for community comments on it (and revisions to
> it) -- whether those calls are issued by the RSE or the IAB or
> both should make little difference unless the RSE selection
> process makes a really bad choice. As I have suggested to her,
> if the RSE isn't responsive to that kind of advice and guidance,
> we will have a problem that is far more serious than where a few
> paragraphs are placed or the specific wording that is used in
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rfc-interest