Subject: [L2tpext] draft-l2tpext-l2tp-base-15.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 06 Dec 2004 16:41:07 -0500

Everyone,

You may have seen draft-l2tpext-l2tp-base-15.txt recently
published. This draft is the output of the RFC Editor's changes in
preparing RFC3931 plus editorials contributed by the document
editors. All IANA values have been inserted, editorials and
clarifications discussed since version 14 on this list included, and a
large number of nits taken care of in the "final 48-hours" pass. The
latter is reference to the multitude of hyphens and commas that were
added or deleted, "that" changed to "which" and vice versa throughout,
etc. There were so many of these spotted in the final pass (largely
due to the extraordinarily astute review of one of our editors), that
the RFC-Editor gave the document authors the .nroff file to be edited
directly. The RFC-Editor indicated that the authors should not be shy
about making fixes, and the resultant diff was a bit longer than had
been anticipated. The exhaustive diffs and before/after versions of
the .nroff that was given to the document editors and what was
returned to the RFC-editor may be found here:

http://www.townsley.net/mark/rfc3931-diffs

I have paged through the long diff file, and pulled out those which
seemed more substantive than the simplest of style, consistency or
grammatical fixes. These are included below in this email.

Thomas asked that I make the final draft available to the group for
one final review to ensure that all of the changes are
satisfactory. Assuming no objections, draft-l2tpext-l2tp-base-15.txt
(using the rfc3931-latest.nroff source file within the directory
above) will be exactly what is published as RFC 3931, with the
exception of the Status section boilerplate and associated header
changes. Since we are technically in an extended final 48-hour editing
period, this will be a very short call for review; I will ask Thomas
and the RFC-Editor to release this draft for publishing in one week.

Thanks,

- Mark

*** 2473,2478 ****
--- 2479,2491 ----
   The Preferred Language is the indicated number of octets representing
   the language tag or language range, encoded in the US-ASCII charset.

+ It is not required to send a Preferred Language AVP.  If (1) an
+ LCCE does not signify a language preference by the inclusion of
+ this AVP in the SCCRQ or SCCRP, (2) the Preferred Language AVP
+ is unrecognized, or (3) the requested language is not supported
+ by the peer LCCE, the default language [RFC2277] MUST be used
+ for all internationalized strings sent by the peer.
+
   This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for this
   AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The Length
   (before hiding) of this AVP is 6 plus the length of the Preferred

(Editor's note: This above text seems new, but it is simply being copied
from a later section so that it is not missed.)

*** 2694,2702 ****
   (described in Section 3.3) plus the per-session shared value
   communicated via the End ID AVP.  In the case of a tie, the recipient
   of an ICRQ or OCRQ must compare the received tie breaker value with
! the one that it sent earlier.  The LCCE with the lower value "wins",
! and the "loser" MUST send a CDN with result code set to RC-13-1 (as
! defined in Section 5.4.2) to tear down the session it instigated.  In
   the case in which a tie is detected, tie breakers are sent by both
   sides, and the tie breaker values are equal, both sides MUST discard
   their sessions and restart session negotiation with new random tie
--- 2707,2716 ----
   (described in Section 3.3) plus the per-session shared value
   communicated via the End ID AVP.  In the case of a tie, the recipient
   of an ICRQ or OCRQ must compare the received tie breaker value with
! the one that it sent earlier.  The LCCE with the lower value "wins"
! and MUST send a CDN with result code set to 13 (as defined in
! Section 5.4.2) in response to the losing ICRQ or OCRQ.
! In
   the case in which a tie is detected, tie breakers are sent by both
   sides, and the tie breaker values are equal, both sides MUST discard
   their sessions and restart session negotiation with new random tie

*** 3225,3230 ****
--- 3239,3245 ----
   Remote Session ID
   Serial Number
   Pseudowire Type
+ Remote End ID
   Circuit Status

   .in3
*** 3234,3240 ****
   Random Vector
   Message Digest
   Assigned Cookie
- Remote End ID
   Session Tie Breaker
   L2-Specific Sublayer
   Data Sequencing
--- 3249,3254 ----

*** 3342,3347 ****
--- 3356,3362 ----
   Remote Session ID
   Serial Number
   Pseudowire Type
+ Remote End ID
   Circuit Status

   .in3

*** 3351,3357 ****
   Random Vector
   Message Digest
   Assigned Cookie
- Remote End ID
   Tx Connect Speed
   Rx Connect Speed
   Session Tie Breaker
--- 3366,3371 ----

*** 3772,3780 ****
   wait-reply      Receive ICRP,      Send CDN,        idle
                   Not acceptable     clean up

- wait-reply      Receive ICRQ       Send CDN,        idle
-                                    clean up
-
   wait-reply      Receive ICRQ,      Process as       idle
                   lose tie breaker   ICRQ Recipient
                                      (Section 7.3.2)
--- 3787,3792 ----
*************** idle            Receive ICRP       Send

*** 3938,3948 ****
   wait-reply     Receive OCCN       Send CDN,         idle
                                     clean up

! wait-reply     Receive ICRQ,      Process as        idle
                  lose tie breaker   OCRQ Recipient
                                     (Section 7.4.2)

! wait-reply     Receive ICRQ,      Send CDN          wait-reply
                  win tie breaker    for losing
                                     session

--- 3950,3960 ----
   wait-reply     Receive OCCN       Send CDN,         idle
                                     clean up

! wait-reply     Receive OCRQ,      Process as        idle
                  lose tie breaker   OCRQ Recipient
                                     (Section 7.4.2)

! wait-reply     Receive OCRQ,      Send CDN          wait-reply
                  win tie breaker    for losing
                                     session

*** 4182,4193 ****
   to fit in the category of "globally visible names" [RFC2277] and so
   is represented in US-ASCII.

! The Preferred Language AVP is not mandatory.  If an LCCE does not
! signify a language preference by the inclusion of this AVP in the
! SCCRQ or SCCRP, the Preferred Language AVP is unrecognized, or the
! requested language is not supported by the peer LCCE, the default
! language [RFC2277] MUST be used for all internationalized strings
! sent by the peer.
   .bp
   .ti0
   10.  IANA Considerations
--- 4193,4204 ----
   to fit in the category of "globally visible names" [RFC2277] and so
   is represented in US-ASCII.

! If (1) an LCCE does not signify a language preference by the inclusion
! of a Preferred Language AVP (see Section 5.4.3) in the SCCRQ or SCCRP,
! (2) the Preferred Language AVP is unrecognized, or (3) the requested
! language is not supported by the peer LCCE, the default language
! [RFC2277] MUST be used for all internationalized strings sent by the
! peer.
   .bp
   .ti0
   10.  IANA Considerations

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: [email-masked]
Date: Thu, 09 Dec 2004 10:49:31 +0900

Hello,

> grammatical fixes. These are included below in this email.

Thanks for the 'diff'.  I've found a minor error.
In "General Result Code values for the CDN message(Section 5.4.1)",
the value '12' is unknown.
--
ESAKA Naoki <[email-masked]>
Communication Platform Laboratory          Phone: +81-44-549-2238
Corporate Research and Development Center  Fax:   +81-44-520-1806
TOSHIBA Corporation

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 24 Dec 2004 10:51:55 -0500

Thank you for finding this. Result Code 12 is defined as:

          12 - Disconnecting call due to mismatching SDS value     [RFC3308]

As seen here:

          http://www.iana.org/assignments/l2tp-parameters

Given, however, that the l2tpv3 document identifies value 6-11 as "Reserved" 
this should either be 6-12, or the line removed entirely. I am tempted to just 
remove it as l2tpv3 shouldn't necessarily have to speak as to whether non-l2tpv3 
result codes are reserved or not.

Thanks,

- Mark