Subject: Re: Layer Two Tunneling Protocol 'L2TP' - Working Group L...

From: Pat_Calhoun/MW/US/[email-masked]
Date: Tue, 27 Jan 1998 10:26:16 -0600

Subject:
Re: Layer Two Tunneling Protocol 'L2TP' - Working Group Last
---------------------------------

Yes it is optional, but my understanding of the IETF procedure is
that any optional features which no one implement are removed
from the draft and moved forward.

PatC

Matt Holdrege <[email-masked]> AT Internet on 01/27/98 08:02:24
AM

To:   [email-masked] AT Internet@ccmail
cc:   [email-masked] AT Internet@ccmail, [email-masked] AT
      Internet@ccmail, [email-masked] AT Internet@ccmail
Subject:  Re: Layer Two Tunneling Protocol 'L2TP' - Working Group
      Last

Someone correct me if I'm wrong, but...

I thought that disabling windowing was simple. But that enabling
it was the tricky part. But that is an optional feature right? So
it's not required for interoperability, right?

At 04:50 PM 1/26/98 -0500, Rich Shea wrote:
>I third the sentiment.  The functionality Pat describes below
makes the >delta between the draft-08 and -09 versions more than
just editorial.
>
>Pat Calhoun wrote:
>>
>> I also agree. Until we test this autodetection of windowing
>> enabled/disabled on the data channel, which I still think is a
>> horrible
>> idea and a gross violation of layering, will we know whether
the
>> current
>> L2TP is ready for prime time.
>>
>> PatC
>>
>> Philip Rakity <[email-masked]> AT Internet on 01/26/98
10:11:04 AM
>>
>> To:   Karl Fox <[email-masked]> AT Internet@ccmail
>> cc:   [email-masked] AT Internet@ccmail, [email-masked] AT
>>       Internet@ccmail
>> Subject:  Re: Layer Two Tunneling Protocol 'L2TP' - Working
Group Last
>>
>> Karl,
>>
>> I am against doing this.  We should wait until the
interoperability
>> testing
>> at the end of February.
>>
>> We have asked on the mailing list if we can test with folks
and have >> received no offers.  I also telephoned the CISCO
folks to see if they >> wanted to test, but the answer was that
they were not ready.
>>
>> I believe that until testing is done, it is inappropriate to
move L2TP >> forward.
>>
>> regards,
>>
>> Philip Rakity
>> FlowPoint
>>
>> On Mon, 19 Jan 1998, Karl Fox wrote:
>>
>> > This is last call.  I will advise the area directors that we
 want to
>> >
>> take L2TP (draft-ietf-pppext-l2tp-09.txt) to Proposed Standard
 on >
>> Monday
>> February 2, 1998 unless there is substantive comment raised on
 >
>> either of
>> the [email-masked] or [email-masked] mailing lists.
>> > --
>> > Karl Fox, servant of God, employee of Ascend Communications
>> > 655 Metro Place South, Suite 370, Dublin, Ohio  43017   +1
614 760
>> 4041
>> >
>>
>> Received: from usr.com (mailgate.usr.com) by robogate2.usr.com
 with
>> SMTP
>>   (IMA Internet Exchange 2.02 Enterprise) id 4CCD4450; Mon, 26
 Jan 98
>>   12:21:58
>> -0600
>> Received: from bodhi.zendo.com by usr.com (8.8.5/3.1.090690-US
>> Robotics)
>>  id MAA15133; Mon, 26 Jan 1998 12:03:20 -0600 (CST)
>> Received: (from daemon@localhost) by bodhi.zendo.com (8.
8.5/8.6.12) id
>> IAA18437
>> for l2tp-xplod; Mon, 26 Jan 1998 08:06:48 GMT
>> Received: from santaclara01.pop.internex.net
>> (santaclara01.pop.InterNex.Net
>> [205.158.3.18]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP
id
>> IAA18426
>> for
>> <[email-masked]>; Mon, 26 Jan 1998 08:06:46 GMT
>> Received: from flowpoint.com ([192.84.210.69])
>>           by santaclara01.pop.internex.net (Post.Office MTA
v3.1.2
>> release
>>           (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP
>>           id AAA16149; Mon, 26 Jan 1998 10:11:23 -0800
>> Received: from localhost (pmr@localhost)
>>           by flowpoint.com (8.8.7/8.8.4) with SMTP
>>    id KAA27455; Mon, 26 Jan 1998 10:11:04 -0800
>> Date: Mon, 26 Jan 1998 10:11:04 -0800 (PST)
>> From: Philip Rakity <[email-masked]>
>> X-Sender: pmr@flowpnt
>> To: Karl Fox <[email-masked]>
>> cc: [email-masked], [email-masked]
>> Subject: Re: Layer Two Tunneling Protocol 'L2TP' - Working
Group Last
>> Call
>> In-Reply-To: <[email-masked]>
Message-ID:
>> <Pine.LNX.3.96.980126100910.27424A-100000@flowpnt>
>> MIME-Version: 1.0
>> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
>Richard Shea                [email-masked],
[email-masked]
>New Oak Communications                            978-266-1011
x210
Matt Holdrege           http://www.ascend.com   [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 27 Jan 1998 12:42:43 -0500

> from the draft and moved forward.

For a document going to Proposed Standard, no implementation
experience is *required*. Having some certainly helps, but as long as
folks think the draft is implementable (i.e., it doesn't contain stuff
that gives folks heartburn when they read it) implementation
experience is not required.

When going to Draft Standard, that is when interoperability experience
is first required, and all features (including optional ones) must
have been shown to be interoperable through implementations. If no
such experience is available for a feature or option (i.e,. no two
implementations could be found), that feature must be removed before
the document can be advanced.

Thomas

---

From: Philip Rakity <[email-masked]>
Date: Tue, 27 Jan 1998 11:25:30 -0800 (PST)

Thomas,

So,  why are there proposed drafts editions of the spec, if some
reasonable interoperability testing is not required.

Philip

---

From: Brian Lloyd <[email-masked]>
Date: Tue, 27 Jan 1998 15:47:20 -0800

I have been keeping a low profile here but the recent discussion about
going to proposed standard prompts me to speak up.

Please look at the process that PPP went through from the early part of
this decade to reach its current state.  The original docs were unclear and
sometimes misleading which did not become fully apparent until we were
actively working on implementations. (Karl, you should certainly remember
that because you, in your original Morningstar guise, were almost always
the first to implement everything in PPP.)

So before rushing to draft standard, let's get a bit more experience under
our collective belt.  Hopefully that will also help restrain vendors with a
propensity toward the, "but we already implemented it in accord with the
draft standard and now it is in 200 million boxes so we can't change it
now," attitude.

Remember:

              Rough consensus and working code.
                                  !!!!!!! !!!!

The rest will fall into place of its own accord.

Brian Lloyd                                    Lucent Technologies
[email-masked]                       3461 Robin Lane, Suite 1
http://www.livingston.com                      Cameron Park, CA  95682
+1.530.676.6399 - voice                        +1.530.676.3442 - fax    O-

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 27 Jan 1998 15:22:37 -0500

> reasonable interoperability testing is not required.

See RFC 2026 Section 4.

Some points about "Proposed Standard", section 4.1.1

   "The entry-level maturity for the standards track is "Proposed
   Standard"..."

   "Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification..."

   "...further experience might result in a change or even retraction of 
    the specification before it advances..."

---

From: Thomas Narten <[email-masked]>
Date: Wed, 28 Jan 1998 07:21:39 -0500

Brian,

> the first to implement everything in PPP.)

WGs are always encouraged to hold back documents that they feel are
not quite ready for prime time. 

> our collective belt.

I think you probably meant Proposed Standard rather than Draft (yes
the Proposed->Draft->Standard sequence is a bit confusing). A document
can't go to Draft Standard directly; it must sit as a Proposed
Standard for at least six months as well as satisfy some
interoperability hurdles (see RFC 2026 for the details).

> Hopefully that will also help restrain vendors with a

As Mark pointed out in another message, Proposed Standards are not set
in stone (again, see RFC 2026). The idea with issuing a document at
Proposed is that folks generally think it is in good enough shape (not
necessarily perfect) that further iteration of the document has
reached the point of diminishing returns, in the absence of feedback
from implementations and deployment.

At the same time, WGs do need to think about the implications of
wide-scale deployment resulting from the issuing of an immature
document as a Proposed Standard. A WG may well decide to iterate on a
draft a bit longer until they are confident that it is ready for prime
time.

Thomas