Subject: Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC

From: Bruce Lilly <[email-masked]>
Date: Wed, 2 Mar 2005 11:40:44 -0500

The IESG Secretary announced, via the IETF-Announce list:
> The IESG has received a request from the TOOLS team to consider the 
> following document:
> 
> - 'Requirements for IETF Draft Submission Toolset '
>    <draft-ietf-tools-draft-submission-07.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2005-03-28.

I've suggested (via Reply-To) discussion on the IETF list.

> Note that this is an unusual document, in that it doesn't specify a protocol
> or a procedure; instead, it specifies requirements for a tool to make IETF
> procedures run more smoothly. The process that produced this (the Tools team)
> is itself an experiment; in addition to commenting on the content of the
> document, comments on whether or not it makes sense to publish this as
> an RFC, and comments on the process that produced it, are appropriate.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-07.txt

Comment on the substance and proposed procedure:

It seems odd that there is no provision for upload of nroff source
(RFC 2223) mentioned in sections 7 and 8 of the draft.

The draft seems heavily oriented toward use of XML, which (to
paraphrase the draft) some IETFers find unusable for preparation of
drafts and RFCs.

Editorial comment:

The draft could benefit from a grammar/style check; in particular,
insertion of instances of the definite article "the" in appropriate
places would improve readability.

Comment on publication:

Publication as an Experimental RFC seems appropriate.  Alternatively,
entering the Standards Track at Proposed might also be suitable. If
it is expected that there will be multiple implementations, then
Standards Track would be preferable.  Conversely, if it is expected
that the Secretariat will have a single implementation, starting as
Experimental, then submitting a future version as BCP would probably
be more suitable.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 02 Mar 2005 17:29:41 +0100

Hi, maybe some typos or cases of DEnglish on my side:

| A draft which identifier (a.k.a.  filename) is known and
| starts with "draft-ietf-".

s/which identifier/identifier which/ or s/which/whose/ (?)

| documents, Secretariat does not accept

s/, Secretariat/, the secretariat/  AFAIK there is or will be
a new name for the old (trademarked ?) "capital S" secretariat.

| As a result, IESG and RFC Editor may have to spend resources

s /, IESG/, the IESG/  I don't look for further similar cases,
   maybe it's only me who would add tons of "the" to this text.

| If any of the include PIs

s/include/included/

| the Toolset attempts to generate plain text format from
| submitted XML sources (R70/b).
|
| If XML sources are available, the Toolset generates HTML
| draft format

In the latter case it apparently _also_ generates (X)HTML.  In
the former case if an attempt to generate plain text fails, why
not exit with an error mesage instead of _also_ trying HTML ?

| The Toolset requires author email addresses

It should allow to specify an address outside of the submitted
draft for privacy reasons.  The author could use an URL in the
published text, which is not "obviously" a mail address, e.g.
<uri>http://purl.net/xyzzy/mailto/webmaster</uri> in XML.

| "surprise" co-authorships has happened

s/has/have/ or /ships/ship/

| if the interpreter managed to extract draft title

s/draft/a draft/  Obviously I don't insist on a "the".

| An IETF IPR Statement and other boilerplate required for
| drafts according to [RFC3667] and [RFC3668

s/RFC3667/BCP 78/ and s/RFC3668/BCP 79/

Actually I don't understand why "the Toolset" cannot insert an
equivalent ipr="full3667" or ipr="fullshit" on its own behalf,
asking the author how much "fullshit" (s)he's ready to tolerate
at this stage.

Please note somewhere that submissions to the RfC-editor don't
require "fullshit" as long as they cover it by broader rights.
If that's the case, IANAL.

| a standard word-based diff is sufficient short-term

s/sufficient short-term/sufficiently short-term/ or similar,
or only another missing "a" if short-term is a noun.

| Toolset may try several recent xml2rfc versions

It should also try a decent XML validator before xml2rfc based
on the specified DTD.  Skipping the next chapters up to 14.  In
chapter 16 (email-interface) you have the required mail address
even if you can't extract it from the meta-data.

                             Bye, Frank