Re: Issues around sponsoring individual documents

Martin Duerst <duerst@it.aoyama.ac.jp> Sat, 08 September 2007 11:18 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITyKg-0001g2-A7; Sat, 08 Sep 2007 07:18:34 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITyKe-0001fw-Ty for discuss-confirm+ok@megatron.ietf.org; Sat, 08 Sep 2007 07:18:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITyKe-0001fn-KN for discuss@apps.ietf.org; Sat, 08 Sep 2007 07:18:32 -0400
Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITyKc-00072L-Ai for discuss@apps.ietf.org; Sat, 08 Sep 2007 07:18:32 -0400
Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l88BIOoG028369 for <discuss@apps.ietf.org>; Sat, 8 Sep 2007 20:18:24 +0900 (JST)
Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 063e_3736faf4_5dfd_11dc_9376_0014221f2a2d; Sat, 08 Sep 2007 20:18:23 +0900
X-AuthUser: duerst@it.aoyama.ac.jp
Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:51902) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S13849C> for <discuss@apps.ietf.org> from <duerst@it.aoyama.ac.jp>; Sat, 8 Sep 2007 20:07:07 +0900
Message-Id: <6.0.0.20.2.20070908104757.0783acd0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Sat, 08 Sep 2007 16:42:34 +0900
To: "tom.petch" <cfinss@dial.pipex.com>, "Apps Discuss" <discuss@apps.ietf.org>, "Lisa Dusseault" <ldusseault@commerce.net>
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: Issues around sponsoring individual documents
In-Reply-To: <029c01c7f158$a61a3560$0601a8c0@pc6>
References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <029c01c7f158$a61a3560$0601a8c0@pc6>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.4 (+)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc:
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

Two additional comments, one on something Tom says below and
one on James' situation.

At 22:42 07/09/07, tom.petch wrote:

>I have put time and effort into trying to find if and where these I-Ds get
>discussed prior to Last Call and, apart from URI, have largely failed.  I do
>receive and mostly look at each and every I-D announcement but do not always
>realise from the title and description whether or not I whould be interested.

I think this is a valid point. The IETF discourages leaving any potentially
instable pointers in documents, and this includes pointers to mailing
lists, issues lists, and so on. For RFCs, this makes quite a bit of sense
(although it may sometimes go too far), and it tends to affect Internet
Drafts strongly. After all, everybody wants to publish Internet Drafts as
RFCs, so they better conform to the rules for RFCs.

For people with some basic knowlegde about IETF WGs, that's no problem
for WG drafts. Take the group of letters appearing in the draft name
after draft-ietf-, and work from there. However, for individual drafts,
it is a problem. What I have been doing, at least for some drafts, is to
add a special paragraph, ideally in the Abstract (because that goes
out with the announcement), that may read something like this
(taken from an actual draft of mine):
    [RFC Editor: Please remove this paragraph before publication.] This is
    a draft to update RFC 3987 and move towards IETF Draft Standard.
    For an issues list/change log and additional information, please
    see http://www.w3.org/International/iri-edit.
I think we should incourage things like this more.


As for the Atom-related drafts that James was working on,
I think that's one situation where I could understand if the AD
just told the author and the WG: Please make this a WG draft.
I don't want to say that it has to be done that way, but if
there is a WG anyway, and the draft is discussed anyway on the
WG list, and is closely related to the actual WG work
(e.g. an extension, or even a way to discover extensions),
if I were an AD, I'd definitely think about trying to reduce
my workload by having a WG chair do the shephearding ex officio,
rather than politely asking him/her and being declined.
Creating a WG is a huge overhead, but having a WG being
formally responsible for a draft that they discuss anyway
isn't too much overhead. Just an idea.


Regards,    Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp