[L2tpext] draft-ietf-l2tpext-failover - publish request + proto questionnaire
Ignacio Goyret <igoyret@alcatel-lucent.com> Wed, 13 December 2006 21:54 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guc3C-0006xh-2f; Wed, 13 Dec 2006 16:54:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guc3B-0006wN-DO; Wed, 13 Dec 2006 16:54:05 -0500
Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guc39-0005eJ-V5; Wed, 13 Dec 2006 16:54:05 -0500
Received: from horh1.emsr.lucent.com (h135-112-138-211.lucent.com [135.112.138.211]) by hoemail2.lucent.com (8.13.8/IER-o) with ESMTP id kBDLrxI1011777; Wed, 13 Dec 2006 15:53:59 -0600 (CST)
Received: from new-wopr.eng.ascend.com (new-wopr.eng.ascend.com [135.140.53.19]) by horh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id kBDLrwnV011671; Wed, 13 Dec 2006 15:53:58 -0600 (CST)
Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [135.140.53.169]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id kBDLrRk04582; Wed, 13 Dec 2006 13:53:27 -0800 (PST)
Received: from igoyret-t23 (igoyret.lra.lucent.com [135.244.0.239]) by cliff.eng.ascend.com (8.13.1/8.13.1) with SMTP id kBDLrQoV006074; Wed, 13 Dec 2006 13:53:27 -0800
Message-Id: <200612132153.kBDLrQoV006074@cliff.eng.ascend.com>
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Date: Wed, 13 Dec 2006 13:51:39 -0800
To: iesg-secretary@ietf.org
From: Ignacio Goyret <igoyret@alcatel-lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.57 on 192.11.226.42
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: l2tpext-ads@tools.ietf.org, l2tpext@ietf.org, l2tpext-chairs@tools.ietf.org
Subject: [L2tpext] draft-ietf-l2tpext-failover - publish request + proto questionnaire
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/l2tpext>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
Errors-To: l2tpext-bounces@ietf.org
Please, publish the ID draft-ietf-l2tpext-failover-11.txt as Proposed Standard. Here are the answers to the PROTO questionnaire for this document: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. Ignacio Goyret will be the WG Document Shepherd for this document. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed in the l2tpext WG. Further detailed review was performed by Ignacio Goyret. There are no concerns about the extent of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No, we don't believe there is any need for additional review from other areas. The document describes an extension that only affects L2TP. It has been implemented and deployed for some time now, so there is also operational experience to back it up. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? All concerns raised in the mailing list have been addressed. To my knowledge, there aren't any outstanding issues. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There have been no dissenting voices during review and/or WGLC. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Only normative references are included. All the references are already published RFCs. The only draft currently referencing this document is draft-ietf-l2tpext-tunnel-switching-07 (normative reference). (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? The allocations required by this draft have already been done under draft-ietf-l2tpext-failover-04.txt, a previous version of this same document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections on this document using any formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup. * Technical Summary L2TP is a connection-oriented protocol that requires some shared state between the active endpoints. Some of this shared state is vital for operation but may be rather volatile in nature, such as the sequence numbers used on the L2TP Control Connection or on data connections. This document defines protocol extensions to L2TP to facilitate state recovery after a failure of an L2TP Control Connection Endpoint (LCCE). * Working Group Summary There is consensus in the WG to publish this document. * Document Quality The l2tpext WG has reviewed this document. All concerns raised during review and last call have been addressed. At least one vendor has successfully implemented and deployed this extension. Ignacio Goyret is the WG shepherd for this document. ------------------------------------------- Cheers, -Ignacio _______________________________________________ L2tpext mailing list L2tpext@ietf.org https://www1.ietf.org/mailman/listinfo/l2tpext
- [L2tpext] draft-ietf-l2tpext-failover - publish r… Ignacio Goyret