Subject: [Tools-team] [Fwd: Re: Last Call Expired: <draft-ietf-tools-draft-submission>]

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 03 Apr 2005 15:00:45 +0200

Forwarding a comment from Briant regarding the draft submission
draft.

	Henrik

-------- Original Message --------
Subject: Re: Last Call Expired: <draft-ietf-tools-draft-submission>
Date: Fri, 01 Apr 2005 15:18:58 +0200
From: Brian E Carpenter <[email-masked]>
To: Henrik Levkowetz <[email-masked]>

OK, I agree that all of that is constructive comment, so I think
that you should go ahead with a revised version that I can
put in front of the IESG. The quicker the better; personally
I'd like to get this going as quickly as possible so that the
"new" secretariat can get off to a good start.

I don't see any reason to make this Experimental, as one of the
comments suggests. It isn't a protocol. Informational sounds
fine to me. I should mention that comment to the IESG, I guess.

Thanks
    Brian

Henrik Levkowetz wrote:
> Hi Brian,
> 
> On 03/29/2005 11:25 AM Brian E Carpenter said the following:
> 
>> I'm not sure I've seen any last call comments since
>> Mpls, and I wasn't tracking them before then. How about
>> you? (Apart from Barbara's comments,of course, which have
>> to be handled.)
>>
>>     Brian
> 
> 
> There were 2 other responses, quoted below.  My understanding
> of these are that they require some cleanup, but no substantive
> changes:
> 
> On 03/02/2005 05:29 PM Frank Ellermann said the following:
> 
>> 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
> 
> 
> On 03/02/2005 05:40 PM Bruce Lilly said the following:
> 
>> 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.
> 
> 

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