draft-ietf-l2tpext-failover - publish request + proto questionnaire

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