Subject: Re: New ID-Checklist to replace ID-nits (fwd)

From: Pekka Savola <[email-masked]>
Date: Tue, 25 May 2004 22:21:00 +0300 (EEST)

I don't think I've seen any answer from the Powers that Be on whether 
RFC2026 is still a "good enough" boilerplate esp. for old work.

Please comment on that.

---------- Forwarded message ----------
Date: Mon, 24 May 2004 09:19:21 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Re: New ID-Checklist to replace ID-nits (fwd)

On Fri, 21 May 2004, Harald Tveit Alvestrand wrote:
> I assume most of you saw this message on ietf-announce.
> But since it's especially important to the WG chairs, I'm forwarding it to 
> you directly.

One critical question: are boilerplates based on RFC2026 still OK?

I mean, there are a lot of drafts, work-in-progress, which have been
created with old tools supporting RFC2026 only, and changing the tools
during the process could take a bit of time..

> ---------- Forwarded Message ----------
> Date: 20. mai 2004 09:34 -0400
> From: The IESG <[email-masked]>
> To: IETF-Announce
> Subject: New ID-Checklist to replace ID-nits
> 
>     As you probably all know, we have used the ID-nits for a few
>     years to help you all to prepare your Internet-Drafts such that
>     they will process faster through the AD-review, IETF Last Call
>     and IESG approval process.
> 
>     The name was somewhat wrong in that it is more a serious checklist
>     than merely "nits" (however, there are some nits too).
>     The IESG, RFC-Editor and IANA have evaluated the checklist, and
>     a new (improved) ID-Checklist is now available at
> 
>             http://www.ietf.org/ID-Checklist.html
> 
>     Please help us all by actually CHECKING your Internet-Draft BEFORE
>     you pass it on to your AD and the IESG via a "request to publish".
>     It will help to make the process go faster and reduce the workload
>     on all of us if your document has been checked and complies with
>     the guidance/rules in the ID-Checklist.
> 
>     Thanks, the IESG
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> 
> 
> 
> ---------- End Forwarded Message ----------
> 
> 
> 
> 
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 25 May 2004 15:55:52 -0400

In message <[email-masked]>, Pekka Savola 
>RFC2026 is still a "good enough" boilerplate esp. for old work.

Speaking for myself only, and not as either an AD nor as the IPR wg 
chair, there is absolutely no need for a crash effort to update old 
I-Ds to have the new boilerplate.  Conversely, documents being 
submitted to the IESG should have the new boilerplate.

		--Steve Bellovin, http://www.research.att.com/~smb

---

From: [email-masked] (Scott Bradner)
Date: Tue, 25 May 2004 16:54:49 -0400 (EDT)

> RFC2026 is still a "good enough" boilerplate esp. for old work.

I'd say "no" since rfc 3667 and 3668 have been approved and published

Scott

---

From: [email-masked] (Scott Bradner)
Date: Tue, 25 May 2004 17:50:44 -0400 (EDT)

>  there is absolutely no need for a crash effort to update old
> I-Ds to have the new boilerplate. 

agreed - but there is little reason to not change the boilerplate
when an ID is updated for other reasons

Scott

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 May 2004 00:55:50 +0300 (EEST)

> when an ID is updated for other reasons

Remember, many folks aren't hand-editing their documents with notepad
:).  Some may use Word templates (where changing this is probably
possible).  Quite a few use their more or less custom nroff (-based)  
scripts (at least for earlier work items), and updating those could be
painful.  Those who have used xml even for the earlier work are in a
simple situation, but I'm not sure how feasible this is considering
xml2rfc hasn't been around and deployed for all that many years yet.

I.e., what I'm saying is that changing the boilerplates might in many 
cases also imply changing the document formatting tools in flight, 
which might be considered undesirable just for this purpose.

---

From: [email-masked] (Scott Bradner)
Date: Tue, 25 May 2004 17:59:12 -0400 (EDT)

> which might be considered undesirable just for this purpose.

fwiw - mtr's XML tools support the new boilerplate

Scott

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 May 2004 01:11:57 +0300 (EEST)

> fwiw - mtr's XML tools support the new boilerplate

And if you read the whole message, you'll note why this is a
non-starter or undesirable for many on-going projects, i.e., which
just don't use xml2rfc, or were started before xml2rfc became (or is
becoming) mainstream.

---

From: Jonne Soininen <[email-masked]>
Date: Wed, 26 May 2004 10:34:22 +0300

Hi,

I agree with Pekka and Steve. I think all the new I-Ds should have the
new boiler plate, but there should be a "transition period" to the new
boiler plate for the existing I-Ds. 

For example, the users that use the word template have to do quite a bit
copy-pasting around.

Cheers,

Jonne.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 May 2004 07:45:38 -0400

Hi Pekka,

In a sea of individual opinions, I'll add mine...

There is no checking of the boilerplate on I-D submission, so there 
is no hard date by which all I-Ds need to be updated to the new 
boilerplate.

However, the IESG will require the new boilerplate when documents are 
submitted for publication as RFCs.

Most WG I-Ds are intended for publication as RFCs eventually.

While it is true that changing or updating tools or templates may 
result in formatting glitches or errors, I don't see any advantage to 
delaying that transition to the very end of the process when glitches 
or errors may result in more wasted time and delay than earlier.

So, I would strongly suggest that WG chairs require that their 
editors update the boilerplate in all of their WG I-Ds sooner, rather 
than later.  This also has the advantage of making the new IPR 
policies as visible and as clear as possible to the WG and other IETF 
contributors.

Just my $.02

Margaret