Re: L2TP failover nits

Hi Vipin,
While reviewing your draft in preparation for publication, I found
a few details that need answers.

* Introduction:
  There are a few things which are not clearly answered in this draft.
  For instance, who are the players? (I assume there are three)
  A diagram like this (assuming it is correct) would go a long way to help:

                                            +--------------+
                                            | L2TP active  |
    +----------+                        ----| endpoint (A) |
    |   L2TP   |                       /    +--------------+
    | endpoint |-----( IP cloud )-----/
    |    (R)   |                      \     +--------------+
    +----------+                       \    | L2TP backup  |
                                        ----| endpoint (B) |
                                            +--------------+

   Using the above diagram's reference points, R, A and B, is it true that
   the L2TP endpoints are:
     - R and A for "old tunnels"
     - A and B for "recovery tunnels" (or is it R and B?)
     - R and B for "recovered tunnels"

* Terms:
  The terms "data channel failure" and "control channel failure" are used
  throughout the draft but there is no explanation what do you mean.

* Page 3 (nitpicking):

     "...For tunnel sessions,
     the inconsistency in its sequence numbers, when used, can cause
     significant data loss thus giving perception of "service loss" to the
     end user."
  to 
     "...For tunnel sessions,
     the inconsistency in its sequence numbers, when used, can cause
     significant data loss thus giving the perception of "service loss" to the
                                       ^^^
     end user."

* Page 4:
  This text needs clarification or a rewrite:

  "Upon establishing the recovery tunnel two endpoints reset
   their control and/or data channel; after which recovery tunnel could
   be torn down."

  The use of the word "reset" is one of the confusing points here.

  Is this what you meant?

     "Using the recovery tunnel, the two endpoints reestablish the
      control and/or data channels of the recovered tunnel. The recovery
      tunnel can then be torn down."

* Page 4: (nitpicking)
     "To synchronize, two endpoints first silently clear the sessions that
     were not in established state. At this point they can allow new
     sessions to establish on the recovered tunnel."
  to
     "To synchronize, the two endpoints first silently clear the sessions
                      ^^^
     that were not in the established state. At this point, they can allow
                      ^^^                                 ^
     new sessions to establish on the recovered tunnel."

* Failover Capability AVP:

  - There is no explanation of what is the meaning of a C-bit set to 0,
    and it is not clear to me why is the C-bit needed at all. Isn't the
    presence of this AVP sufficient indication that the sender is capable
    of understanding failover?

  - This text (for the D-bit) needs rewording:

      "This bit is applicable only for the sessions using sequence numbers
       on the data channel i.e. data channel failure on the system not
       exhibiting D bit capability could still recover sessions that do
       not use sequence numbers."

    The section after "i.e." needs special care.

* Section 2.2:
- page 5 (nitpicking)
    "For control channel failure, failed endpoint establishes a new..."
  to
    "After a control channel failure, the failed endpoint establishes a new..."
     ^^^^^^^                          ^^^

- page 6:
  "...recovery tunnel...
   An endpoint SHOULD not send any control message on this tunnel, other than
   those required to manage the life of the recovery tunnel."

  I think we should be explicit as to which control messages should or should
  not be used. An explicit list helps interoperability.

- Tunnel Recovery AVP:

  How does an endpoint know which tunnels to recover? Should this information
  somehow have been exchanged between points A and B (in the above diagram)
  before the failure?

  The draft should provide some hints. If it is intended to be implementation
  specific, it should say so.

- Suggested Control Sequence AVP:

  I find odd that the name of the AVP includes the word "suggested" in it but
  the text describing it says that if present, the values of Nr and Ns MUST be
  set as indicated. If that's so, then the word "suggested" seems inappropriate.

There are more nitpicking details, but I really have to run now.
We can pick this up upon my return in mid-Jan.

Also, idnits-1.82 (http://tools.ietf.org/tools/idnits/) notes the
following issues that may need to be corrected:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack separate sections for Informative/Normative
    References.

    Checking conformance with RFC 3978/3979 boilerplate...

  * Found rfc3978 Section 5.4 paragraph 1 boilerplate (on line 616), which
    is fine, but *also* found rfc2026 Section 10.4C paragraph 1 boilerplate on
    line 33. It should be removed.

  (rfc2026 Section 10.4C paragraph 1 text:
    "Copyright ([Cc]) The Internet Society (2005).  All Rights Reserved.")

  (rfc3978 Section 5.4 paragraph 1 text:
    "Copyright (C) The Internet Society (2005).")

  * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure
    Invitation. 

  (rfc3979 Section 5 paragraph 3 text:
    "The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    ietf-ipr <at> ietf.org.")

Cheers,
-Ignacio