Re: [Tsvwg] WGLC on the SCTP Implementer's Guide (draft-ietf-tsvwg-sctp-impguide-14.txt)

"Brian F. G. Bidulock" <bidulock@openss7.org> Thu, 25 August 2005 06:21 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8B7F-0007QX-2J; Thu, 25 Aug 2005 02:21:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8B7D-0007QP-FR for tsvwg@megatron.ietf.org; Thu, 25 Aug 2005 02:21:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01331 for <tsvwg@ietf.org>; Thu, 25 Aug 2005 02:21:30 -0400 (EDT)
Received: from gw.openss7.com ([142.179.199.224] ident=[7igG5Z/fW+/NwzQxUzUudhwJl7BCH07F]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8B7f-0007nM-IC for tsvwg@ietf.org; Thu, 25 Aug 2005 02:22:00 -0400
Received: from ns.pigworks.openss7.net (IDENT:hUWB/xkKOtWPwr9Vwj387x4l53K5Wt/U@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j7P6LHQ16358; Thu, 25 Aug 2005 00:21:17 -0600
Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j7P6LH220661; Thu, 25 Aug 2005 00:21:17 -0600
Date: Thu, 25 Aug 2005 00:21:17 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Joe Touch <touch@ISI.EDU>
Subject: Re: [Tsvwg] WGLC on the SCTP Implementer's Guide (draft-ietf-tsvwg-sctp-impguide-14.txt)
Message-ID: <20050825002117.A20487@openss7.org>
References: <200508231831.j7NIVH222729@vapor.isi.edu> <430B8125.50404@isi.edu> <430CBA01.6010105@stewart.chicago.il.us> <430CDA01.70701@isi.edu> <430CF9D8.2070305@stewart.chicago.il.us> <430D4EDB.9000606@isi.edu>
Mime-Version: 1.0
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <430D4EDB.9000606@isi.edu>; from touch@ISI.EDU on Wed, Aug 24, 2005 at 09:53:47PM -0700
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: Randall Stewart <randall@stewart.chicago.il.us>, tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0631753957=="
Sender: tsvwg-bounces@ietf.org
Errors-To: tsvwg-bounces@ietf.org

Joe,

On Wed, 24 Aug 2005, Joe Touch wrote:

> > 
> > My understanding of the proceedure will be:
> > 
> > a) I-G is last called and we get comments etc
> > b) The I-G will progress through the IESG and RFC editor
> >    to Informational status
> > c) When the I-G hits the RFC editors queue I will start
> >    the 2960Bis, based just on the I-G.

What?  Meaning that the WG will not be allowed to make changes
or properly comment or go through last call on the 2960Bis
document.  That sounds highly irregular.  It might be necessary
to challenge such a document.

> > d) When the Bis finishes out the I-G's RFC will be
> >    changed to Historic.. aka here are the considerations
> >    as to how we changed the document from 2960 to xxxxx


> 
> This process doesn't seem productive. I am not in favor of creating new
> documents which are destined to become historic on definite, short
> timescales (esp. those that might be considered a few I-D cycles).
> 
> Informational doesn't seem like it ought to ever go to Historic unless
> its an informational spec. RFC2026 talks about specifications going to
> historic, and this isn't a specification - or doesn't seem to be named
> such. I'd prefer the name reflect that it is a spec if that's the case,
> but I still don't see why we're creating deliberately ephemeral RFCs.
> 

I agree.  The RFC editor's queue is far too deep to be placing
such things in it.  Also, with the way things stand, and the
lower priority that is placed on informational RFCs, the 2960bis
PS stands a chance of beating it out of the RFC editor's queue.

What I can't understand is why we don't follow this process:

a)  Apply the changes from the I-G document to RFC 2960 creating
    draft-ietf-tsvwg-rfc2960bis-00.txt as a standards track I-D
    to replace RFC2960 (and RFC3309).

b)  Solicit comments on the I-D.

c)  Last call draft-ietf-tsvwg-rfc2960bis-xx.txt as a new PS
    replacing RFC2960 (and RFC3309).

skipping three of the four steps in the plan at the top of this
message.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg