Re: [xmpp] next steps

Ben Campbell <ben@nostrum.com> Wed, 20 October 2010 22:17 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: xmpp@core3.amsl.com
Delivered-To: xmpp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219AB3A695D for <xmpp@core3.amsl.com>; Wed, 20 Oct 2010 15:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.603
X-Spam-Level:
X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9DzZTqB06lI for <xmpp@core3.amsl.com>; Wed, 20 Oct 2010 15:17:07 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C1D873A6977 for <xmpp@ietf.org>; Wed, 20 Oct 2010 15:17:06 -0700 (PDT)
Received: from dn3-174.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9KMIddj035104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Oct 2010 17:18:39 -0500 (CDT) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <4CBEE222.50809@stpeter.im>
Date: Wed, 20 Oct 2010 17:18:39 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3CA5BDB-D2CE-4C14-9597-75E92E41B702@nostrum.com>
References: <4CAE44AB.6060602@stpeter.im> <4CBA6551.1000709@stpeter.im> <4CBEE222.50809@stpeter.im>
To: XMPP Working Group <xmpp@ietf.org>
X-Mailer: Apple Mail (2.1081)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Subject: Re: [xmpp] next steps
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2010 22:17:11 -0000

I'd like to second this. 

Technically, when we submitted the publication request to the IESG, that meant the working group felt that it was finished with the drafts, modulo any issues found in the IETF last call or AD review. 

In reality, the working group has continued to work on the drafts. That's mostly okay, as we can just treat the additional working group feedback as IETF LC feedback. But we should avoid substantive post pubreq changes unless we can articulate a good reason. By "good reason", I'm talking about "things are broken" reasons, not "we thought of a way to make it a little better" reasons. If the IESG feels like too many changes have occurred post publication request, they could in fact toss it back to us and start the process over (I'm not saying I think we've reached that point, just that it's something to watch out for.)  

Sometimes the hardest part of the process in knowing when we're done.

Thanks!

Ben.

On Oct 20, 2010, at 7:35 AM, Peter Saint-Andre wrote:

> And a further note. :)
> 
> The deeper we progress in the publication process, the less time we have
> for discussion (yes, we could keep talking about these specs forever,
> but at some point we need to declare *this* set of revisions done, with
> the understanding that we might collect errata and implementation
> reports over the next ~12 months and then publish a further revision).
> IETF folks (e.g., our WG chairs and responsible AD) also prefer to see
> smaller and smaller diffs as we get later in the process -- we don't
> want to be making major changes close to the release date! In the
> interest of full disclosure, I have generated diffs between the versions
> that were submitted for IETF Last Call and my current working copies.
> Please check these for sanity and compare them to the list discussion. I
> would prefer not to make further changes between now and Monday's cutoff
> date, but if you have any significant concerns then please do raise them
> as soon as possible.
> 
> http://xmpp.org/internet-drafts/draft-ietf-xmpp-3920bis-18-from-17.diff.html
> 
> http://xmpp.org/internet-drafts/draft-ietf-xmpp-address-06-from-05.diff.html
> 
> http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-16-from-15.diff.html
> 
> For reference, my current working copies are here:
> 
> http://xmpp.org/internet-drafts/draft-ietf-xmpp-3920bis-18.txt
> http://xmpp.org/internet-drafts/draft-ietf-xmpp-3920bis-18.html
> 
> http://xmpp.org/internet-drafts/draft-ietf-xmpp-address-06.txt
> http://xmpp.org/internet-drafts/draft-ietf-xmpp-address-06.html
> 
> http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-16.txt
> http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-16.html
> 
> Thanks!
> 
> Peter
> 
> On 10/16/10 8:54 PM, Peter Saint-Andre wrote:
>> A further note about the schedule: Gonzalo issued the IETF Last Calls on
>> October 7 and they expire on October 21. The cut-off date for submitting
>> revised Internet-Drafts before IETF 79 is October 25 at 24:00 UTC.
>> Therefore I plan to submit 3920bis-18, address-06, and 3921bis-16
>> sometime between the end of the Last Calls and the cut-off date
>> (probably on Monday, October 25).
>> 
>> On 10/7/10 4:07 PM, Peter Saint-Andre wrote:
>>> Because some folks on this list are new to IETF process, I figured I'd
>>> provide a brief description of where we go from here.
>>> 
>>> 1. Gonzalo Camarillo, the responsible Area Director, has issued an IETF
>>> Last Call on our three main documents. Because these I-Ds are the
>>> product of an IETF Working Group, the IETF Last Call will last two
>>> weeks. This is essentially your last opportunity to provide feedback!
>>> 
>>> 2. During IETF Last Call, the documents will be reviewed by several
>>> cross-area teams within the IETF, including the "GEN-ART" review team
>>> and the Security Directorate. We'll expect at least some feedback from
>>> those teams. And at this stage anyone in the Internet community can
>>> provide feedback as well.
>>> 
>>> 3. After IETF Last Call, your friendly document editor will work as fast
>>> as possible to address any feedback we've received.
>>> 
>>> 4. The documents will then be scheduled for disussion during an IESG
>>> telechat. There are upcoming telechats on October 28, November 18,
>>> December 2, and December 16. Before the telechat, all the members of the
>>> Internet Engineering Steering Group will review the specs and also
>>> provide feedback (well, except for me, because I'll recuse myself). If
>>> there are "DISCUSSES" and "COMMENTS" lodged then your document editor
>>> will need to address those, as well.
>>> 
>>> 5. Assuming the documents are approved by the IESG, they will then be
>>> handed off to the RFC Editor team for final copy editing, proofreading,
>>> reference checking, etc. In particular, the documents will not be
>>> published as RFCs until all normative references have also advanced;
>>> this includes especially draft-saintandre-tls-server-id-check, which is
>>> on a parallel track to consideration by the IESG (I'm working to push
>>> out a revised version of that one in the next few days).
>>> 
>>> As you can see, because there are still many steps left in the process,
>>> it might be a few months before these "bis" drafts are published as
>>> RFCs. That gives you all plenty of time to bring your implementations
>>> into conformance. ;-)
>>> 
>>> Just so you know!
>>> 
>>> Peter
>>> 
> 
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp